It seems like I might need to understand Devirtualise MMIO quirk and MMIO Whitelist to achieve this, but I have no understanding on how I might add a quirk ( if that's the correct terminology ) to say "heh, please reserve these memory address for talking to my NVMe drives." Any suggestions happily received.
I don't have answers for your questions on iomapper config, but I can wave my hands to explain that MMIO is memory-mapped IO and DMA in the context of VT-d, with all the attendant security implications of letting hot-plugable PCIe devices (Thunderbolt) and VMs rummage around in the underlying hardware (kernel) address space. Basically the memory maps used by devices need to be visualized along as does user space, because like user processes, devices can no longer be considered trusted by the kernel. This is a big change from the PC design age before Thunderbolt where the case could be considered a security boundary. As to how ASLR fits into this puzzle I don't know the details, but it's safe to assume it does.
On these forums I have never seen iomapper config pertained to NVMe drives, but the config is late game hack, but this doesn't mean it can't pertain... You are on the bleeding edge.
Iomapper come up in context of z690 and Thunderbolt, and also regaining compatibility with i225_v rev3 ethernet on Monterey. There are finer points as to a need for socialize specialized DMAR config you will need to suss out.
You are right to associate this with CaseySJ and his large valuable z690 thread, where you will find his reference EFI with all the trimmings.
(—Pertaining to iomapper, I included TB config such that macOS detects the Asus Hero's z590 Maple Ridge controller, but TB has never been tested on my build.)
The reason iomapper config is pertinent to you is that you may have built from a reference EFI that has iomapper details that create an edge case affecting NVMe for your HW combo.
FWIW I do have VT-d enabled as I use VMFusion to run a few VMs. Losing the ability to use VMWare is a bit of a deal breaker ( it's one of many reasons I don't want to move to Apple Silicon ).
OK. Can you be specific about what motherboard, CPU, version of MacOS and version of OpenCore you are using, and what exact WD drive you are suggesting? WD SN850 isn't for example explicit enough as there is now a WD SN850X and for all I know I'll by a WD SN850X and get a "oh, that's not proven to be compatible you need to buy a XXXX".
I'd even go so far as to ask has anyone higher confidence in specific capacity drives? I need a 2TB, but for obvious financial reasons would like to test and have some confidence using a 250GB or 500GB drive...
I don't think drive size has any bearing on your situation.
I'm using a z590 Asus Hero with 11900K and an original SN750 Black. This drive has been reliably compatible with my kit since day one, starting with Big Sur.
My back story is that I was gifted a dream build in 2021 which I decided to hack to replace a trusty, venerable 2008 Mac Pro.
I had started my build with a 10900K and the Sabrent Rocket 4, which I chose for PCIe4, but I has to purchase kit a month ahead of Intel's 11th gen release.
—This thread came about from my discovering that z590 Rocket 4 was so incompatible with Big Sur that two drives were wrecked— that is, became bricked, for unknown reasons, but possibly related to thermal overload. My thought was if a normally functioning system can wreck drive HW not just lose data that seems a special new kind of concern that deserved its own topic. Along the way I learned that Sabrent is a vertical integrator and their support isn't up to job of debugging compatibility and they likely knew they had a thermal edge case.
I switched to a SN750 Black to resolve the Rocket problems, which it did resolve.
Ultimately I got a 11900K to play with and I sidelined the SN750 for PCIe 4 SK Hynix Platinum, which has been running well in daily use since I got it 2 years ago.
—I also run this system maximally overclocked, which at full tilt 300W happens to make it's performance on par with an M1 Pro Macbook running on a battery. So I learned a lesson about the future of Mac the hard expensive way, but not as bad as poor blighters who bought a 2019 Mac Pro.
I have VT-d enabled and CaseySJ's recommended iomapper config for TB support which also gives me native i225_v compatibility in Ventura.
—I did run into a hazard where running backups to the SN750, which I now use to stage OS updates, was causing a system freeze. By pure luck, this turned out to be resolved by pulling the drive, cleaning its connector and re-installing.
x x x
Re your specific plight...
I looked a little at this "loss of MMIO space" panic on the googz:
The that the panic message is written as such "3rd party NVMe controller" shows Apple engineering knows there's a compatibility hazard.
This problem is reported with actual Macs at Apple Discussions, and also at Macrumors Unsupported, with no satisfying resolution. So it's not just a hack thing.
There are reports of this MMIO problem here on tonymacx86, from 3 years ago on another thread. 3 pages with no resolution.
It's mentioned as intermittent by one poster at Mavrumors, with no clear pattern of reappearance.
I saw a couple of posts that describe "fixs":
1) A 15 minute youtube about a Macbook reported the fix was to literally hit the laptop.
2) A post about a hack, the fix was to tear down the build, check everything for cleanliness, and put it back together.
I'm sorry nothing I have to say actually helps. It seems your symptoms are truly outlier, like mine with Rocket 4.
Last useless thoughts:
There are bugaboos with this tech that can affect any system:
- Manufacturing defects: outlying devices that are unreliable due to varying tolerances during production.
- Borderline mechanical problems: connection / interface alignment and contamination, i.e., dirt, damaged.
- ESD (electrostatic-discharge damage) a variation of the above that zaps chips.
- Borderline incompatibility, especially over-clocking.
But in history of computing, there have been literal bugs (insects).
So there is sometimes credence to silly solutions, and moreover, some SW may expose bugs while other SW does not.
—Official Intel CPU exploit mitigation is literally a case of:
- Doctor, it hurts when I do this!
- Well, don't do that."
written into microcode.
