This issue goes back a long way, and the blame goes to a combination of OEMs and Intel (and AMD) wanting to sell RAID solutions without needing real RAID hardwa

This issue goes back a long way, and the blame goes to a combination of OEMs and Intel (and AMD) wanting to sell RAID solutions without needing real RAID hardware, and the Intel CPU and chipset teams playing along in ways that they really should not have. In the AHCI era (and earlier), drives connected to a SATA controller, and there were three ways this could work: a) The controller was just a controller. Perhaps it appeared as an AHCI device over PCI. No funny business, and the OS could talk to the drive more or less directly via the controller. b) Hardware, at at least hardware-ish, RAID. A RAID controller speaks SATA to the drives, and the OS speaks some protocol to the controller. It’s possible for the protocol to be obnoxious and to require obnoxious drivers and/or management software, but at least it makes sense. c) Software “RAID” that pretends to be hardware. The CPU really does speak AHCI to the drive, but the vendor has decided to make it pretend to be a high end vendor thing and to integrate it with BIOS. But this is a mess, since the controller really is AHCI. So some hack is done to prevent the OS’s native driver from noticing the AHCI devices and instead let a (generally very bad) vendor “driver” that is actually a full RAID stack claim the devices. This could be as simple as firmware asking the AHCI controller not to report AHCI compatibility. Intel has also enabled this through multiple generations of disgusting kludges. Enter NVMe. Unlike SATA, there is no controller. NVMe drives are PCIe devices. So the choices are different: a) Vendor does nothing except boot support. NVMe drives show up on PCIe just like anything else would. b) Vendor has an actual RAID controller. It’s a device that speaks PCIe to the NVMe devices and, itself, acts as an NVMe (or AHCI) device as seen by the OS. This could work fine, but it’s unlikely to be as fast as the drives themselves (NVMe is fast). c) A truly atrocious hack, again enabled by Intel, in which firmware can ask the Intel PCIe hardware to straight up lie to the OS about what devices are connected. The hardware will try to identify NVMe drives that it’s supposed to hide (which is itself a mess — these drives are all actually just PCIe devices, and there is no reliable way in general to figure out which devices are supposed to be hidden). Then some magic “RAID” driver will do some other kludge to talk to the NVMe devices behind the OS’s back and pretend to be a disk itself. Of course it works poorly. In any case, I wonder if the OP’s machine is actually an example of (b), where the NVMe drives, presumably connected to a fancy backplane, are genuinely connected via PCIe to an actual RAID controller, not the CPU or chipset. If so, a firmware option for “native NVMe” would make no sense, and the actual correct solution is for the OP to arrange for the Windows installer to use the right driver. This has been officially supported, usually in some annoying way, since at least Windows NT 4.0 and probably for quite a bit longer.