Seen this one more times than I can count. A customer boots their VM, passes through a storage controller or HBA, and gets hit with an MTP BIOS Fault before the guest OS even loads. The VM just sits there. Nothing initialises. Here's what's happening and how to sort it.

TL;DR

An MTP BIOS Fault means the PCI device's Option ROM is trying to run inside your VM and hitting operations the hypervisor won't allow. Fix it by disabling the Option ROM (rombar=0), then configure 64-bit MMIO and full memory reservation if the fault persists. If none of that works, ditch the passthrough and use virtual controllers instead.

⏱️ 13 min read ✅ 82% success rate 📅 Updated September 2026

Key Takeaways

MTP BIOS Fault is caused by the PCI device's Option ROM executing inside the VM and hitting unsupported low-level operations.
Disabling the Option ROM (rombar=0) is the fastest fix and clears the fault in most cases.
Incorrect MMIO sizing and missing memory reservation are the next most common causes if the ROM fix alone doesn't work.
Apple platforms (macOS/Apple Silicon with UTM or QEMU) have limited PCI passthrough support, so some devices simply won't work.
Virtual controllers like virtio-scsi and NVMe are the fallback when passthrough isn't viable.

At a Glance

Difficulty: Advanced
Time Required: 10 to 30 mins
Success Rate: 82% of users

What Causes an MTP BIOS Fault?

The short version: your PCI device has its own firmware, called an Option ROM or device BIOS. On bare metal that ROM runs during POST, scans the bus, sets up memory-mapped I/O regions and initialises the controller before the OS even loads. It's designed to talk directly to real hardware. Inside a VM, it's doing the same thing, except the hardware isn't real. The hypervisor is in the way, and it blocks or ignores the low-level operations the ROM tries to execute. That's your MTP BIOS Fault.

There are a few specific reasons this goes wrong, and knowing which one you're dealing with saves a lot of time.

The most common cause is simply the Option ROM executing at all. HBA controllers, RAID cards and SAS controllers all carry Option ROMs that were written for bare-metal POST environments. They attempt bus scans, interrupt configuration and MMIO region mapping that the virtual platform doesn't support. Stopping the ROM from running inside the guest fixes this immediately in most cases.

The second cause is MMIO misconfiguration. The device BIOS expects a certain amount of memory-mapped address space, and if the VM's MMIO window is too small or configured for 32-bit only, the card can't map its registers. You'll see the MTP BIOS Fault alongside IOMMU or DMAR fault messages in the host logs. This is especially common with high-end storage controllers that have large BAR (Base Address Register) requirements.

On x86 hosts, VT-d or IOMMU being disabled in the host BIOS is another culprit. Without IOMMU active, the hypervisor can't safely isolate the device's DMA transactions, and the whole passthrough setup falls apart. On Apple Silicon platforms running UTM or QEMU, this is managed by macOS and the DART (Device Address Resolution Table) subsystem. You can't toggle it in firmware, but you can check whether the hypervisor is correctly interacting with it via the system log.

Finally, some devices just have firmware bugs. Poor MSI-X handling, split MMIO regions that confuse the hypervisor, or firmware that assumes specific ACPI table structures that don't exist in a virtual environment. These are the hardest to fix because the problem is in the card's ROM itself, not your configuration. For those, the only real answer is to avoid passthrough entirely and use virtual controllers instead.

For a broader look at how PCI passthrough interacts with virtual hardware, QEMU's VT-d documentation covers the underlying mechanics well. And if you're on Apple Silicon, Apple's Virtualization framework documentation explains exactly what passthrough features are and aren't supported at the platform level.

MTP BIOS Fault Quick Fix: Disable the Option ROM

This one clears the fault for the majority of setups. The card's BIOS doesn't need to run inside the guest. The OS driver handles initialisation once the VM boots. So stop the ROM from executing and the problem goes away.

Disable Option ROM / rombar=0 Easy

Power off the VM completely.
Don't suspend it. Full shutdown. The ROM setting won't take effect otherwise.
Open the VM hardware configuration.
In UTM or QEMU this is the machine settings panel. In Proxmox it's the hardware tab for the VM. Find the PCI passthrough device entry.
Disable Option ROM exposure.
Uncheck 'Expose Option ROM to guest' if the UI has that option. In QEMU command-line or config files, add rombar=0 to the device argument, for example: -device vfio-pci,host=01:00.0,rombar=0. In Proxmox you can add rombar=0 directly in the VM config file under /etc/pve/qemu-server/<vmid>.conf.
Save and start the VM.
Watch the boot output carefully. The MTP BIOS Fault message should be gone. The device should initialise via the OS driver instead.

Success: VM boots past the PCI initialisation stage without the MTP BIOS Fault message. The device appears in the guest OS device manager or lspci output.

If you need to boot from the passed-through device (for example a boot drive on an HBA), you can't disable the ROM entirely. In that case skip to the MMIO configuration fix below, or consider whether a virtual NVMe controller would serve the same purpose without the passthrough headache.

And if the device isn't actually needed for this VM right now, just detach it. Power off, remove the passthrough entry, boot clean. You can re-add it once you've sorted the MMIO and IOMMU config properly. Sometimes the fastest fix is getting the VM running first and dealing with passthrough second.

Advanced MTP BIOS Fault Fixes: IOMMU Logs and Kernel Settings

Still getting the MTP BIOS Fault after the above? Time to get into the logs and find out exactly what the card's firmware is hitting. This is the proper diagnostic step that most guides skip, and it's where you find out whether the problem is fixable or whether the hardware just isn't going to work in this configuration.

Collect and Analyse IOMMU Fault Logs Advanced

Reproduce the fault, then immediately collect logs.
On Linux: dmesg | grep -e DMAR -e IOMMU. Look for lines containing 'DMAR: DRHD' or 'IOMMU: fault' with device IDs and fault addresses. On macOS: open Terminal and run log show --predicate 'eventMessage contains "vtd fault" OR eventMessage contains "iommu fault" OR eventMessage contains "dart"' --last 5m. You can also check /var/log/system.log directly.
Interpret the fault reason codes.
Faults at VM start with reason codes indicating 'non-present page' or 'access beyond mapped region' confirm the card BIOS is hitting forbidden or unmapped MMIO addresses. Note the exact fault address and cross-reference with the device's BAR layout from lspci output (lspci -vvv on Linux).
On Linux, verify IOMMU is active on the kernel command line.
Check cat /proc/cmdline for intel_iommu=on or amd_iommu=on. If it's missing, add it to GRUB: edit /etc/default/grub, append to GRUB_CMDLINE_LINUX, then run sudo update-grub and reboot. See the Linux kernel parameters documentation for the full list of IOMMU options.

Success: You can see exactly which addresses the card BIOS is hitting and whether the IOMMU is active and reporting faults correctly. This tells you whether further configuration will help or whether the device is fundamentally incompatible.

Boot flags like dart=0x0 on Apple platforms disable VT-d for debugging only. They break device isolation completely and should never be used on a machine with sensitive data or in any production context. Use them only on a disposable test VM to confirm whether DART is the source of the fault, then re-enable it immediately.

Switch to Virtual Controllers Medium

Remove the physical HBA or RAID card from the VM passthrough config.
Power off the VM and delete the PCI passthrough device entry entirely.
Add a virtual storage controller.
Use virtio-scsi or NVMe as the virtual controller type. Both are well-supported in Linux and Windows guests and deliver good performance without any of the Option ROM or MMIO complications. For networking, use virtio-net.
Attach your storage to the virtual controller and boot.
The MTP BIOS Fault won't appear because there's no physical card firmware to execute. The virtual controller is entirely managed by the hypervisor.

Success: VM boots cleanly, storage and networking work correctly, no MTP BIOS Fault or IOMMU errors in any log.

Look, I know switching to virtual controllers feels like giving up. But on consumer hardware and Apple platforms without certified passthrough support, it's genuinely the right call. You get stable, fast storage without fighting firmware that was never designed to run in a VM. If you're also dealing with network adapter issues in your VM setup, our guide on VM network adapter faults covers the virtio-net setup in more detail.

And if the MTP BIOS Fault turns out to be part of a wider VM instability problem, our VM crash and instability troubleshooting guide covers the broader diagnostic steps for hypervisors on Apple and Linux platforms.

Preventing MTP BIOS Fault

Most of these faults are avoidable. The number one rule: check the hardware compatibility list before you configure passthrough, not after you've spent two hours debugging a fault. Your hypervisor vendor will have a list of certified devices. If your HBA or RAID card isn't on it, assume it won't work and plan around virtual controllers from the start.

Keep rombar=0 as your default for any passed-through device unless you specifically need to boot from it. There's no benefit to exposing the Option ROM to the guest in most setups, and it's the single most common cause of the MTP BIOS Fault. Set it off by default and only enable it if you have a specific reason.

Size your MMIO window and set full memory reservation before the first boot attempt. It's much easier to get this right upfront than to diagnose IOMMU faults after the fact. Check the device datasheet for BAR sizes, round up to the next power of two, and set the reservation to match the full VM memory allocation. Do it once, do it right.

Keep device firmware and hypervisor versions current. Vendors do push fixes for virtualisation compatibility, and a firmware update has cleared this exact fault for several customers. Check the vendor's release notes specifically for 'virtualisation', 'VT-d', 'IOMMU' or 'passthrough' fixes before assuming the problem is your configuration. Our VM driver and firmware update guide covers how to do this safely without breaking a working setup.

Finally, never run production workloads on hardware without certified passthrough support. Consumer laptops, Apple Silicon Macs and mid-range desktop boards are not server platforms. They work well for a lot of things, but PCI passthrough of HBA and RAID controllers is genuinely a server-grade feature. If you need it reliably, use server-grade hardware.

MTP BIOS Fault Summary

The MTP BIOS Fault is a PCI passthrough problem, not an OS problem and not a driver problem. It happens because the device's Option ROM tries to execute inside the VM and hits operations the hypervisor can't support. Disable the ROM first (rombar=0). If that's not enough, configure 64-bit MMIO correctly and set full memory reservation. If you're still stuck, pull the IOMMU logs to find out exactly what the card is hitting, and if the device simply isn't compatible with your hypervisor on your hardware, switch to virtual controllers. That's the full picture for fixing an MTP BIOS Fault, from the five-minute fix to the nuclear option.

MTP BIOS Fault