Hi Kevin, filed bug number is FB21888307. I provide partial code on bug. Reply to your question: That address should have come from your driver, so how did it exceed 32 bits? All of our APIs for retrieving a bus address should either provide an address that meets your specification or fail entirely. More to the point, even if they some how did return a larger address, why/how would your driver have written a larger address when it was only prepared to handle a 32 bit address? Yes, address comes from my driver by gen64IOVMSegments API. And at the beginning, I didn't know that the address allocated through the API were always >32 bit, so when I received an address >32 bit, I didn't directly return, but continued to use it, resulting in a kernel panic. Next, the big question is how much memory are you actually trying to map? And have you done any experimentation with smaller mappings? I trying to map 20 KB memory, I have already tried 1 Byte or 4 KB, still get 64-bit address. And maximum DMA data size would set to 8 MB, but I haven't set 8M yet. Thanks!

Hello, may I ask if your driver is a DMA driver for PCIe+FPGA? If so, will using a 64 bit IoVM address for DMA transfer be intercepted by the PCIe root port of the M1 Mac?

Hi Kevin, I haven't checked the code, but I'd expect that you'd need to be page aligned, with would be 16KB (not 4KB). I'm actually not sure why gen64IOVMSegments worked, though it's possible that using the "native" address size changed something. Ironically, I think this might have "just worked" if you'd gone straight to 8MB Let me summarize my current attempts: IODMACommand uses 1B, 4KB, or 16KB page alignment, and allocates IOVM address >32 bits by gen64IOVMSegments(). If the DMA transfer process continues, a kernel panic will occur. PanicSting is apciec[pcic0-bridge]::handleInterrupt: Request address is greater than 32 bits. Using gen32IOVMSegments() will return kIOReturnMessage TooLarge. If I don't set the maximum value of 8M, the result will still be the same, so I think it may not be related to the maximum value. Based on my current attempts, I am focusing on these two issues: Does Apple M silicon not allocate<=32-bit bus addresses to third-party PCIe device (FPGA)? Can Apple M silicon be configured with apciec to not intercept DMA address requests with more than 32 bits?

If you haven't already, take a look at my post here. I haven't checked the code to confirm, but I strongly suspect that calling gen32IOVMSegments with a mask of the wrong size (like 0xFFFFF000) will cause kIOReturnMessageTooLarge, as the true mask range you've specified ("0x00000000FFFFF000") is too large to fit in 32 bits. Yes, I am currently using the inTaskWithPhysicalMask interface in my code, and the masks I have tried are 0 x0000 0000 FFFF FFFFULL，0x0000 0000 FFFF F000ULL, 0xFFFF FFFF，0xFFFF F000, and 0x0, but the result is the same, using gen32IOVMSegments will return the same error. I have also used IOBufferCacheDescriptors:: withOptions and IOBufferCacheDescriptors:: withCapacity to build memory descriptors, but the results have not changed much. If you have time, Could you take a look at the code? I have submitted on the bug. One more thing to add: I have also tried using the prepare() interface of IODMACommand, but there have been no significant changes. Thanks!!