GPU Passthrough to a Virtual Machine Not Detected or Code 43? IOMMU Isolation, Driver Binding & Reset Troubleshooting

2026-10-25 ｜ GPU Repair ｜ About 15 minutes ｜ HK GPU Fix Editorial Team

重點摘要

Passing a whole graphics card to one virtual machine is exclusive: the host must release it, IOMMU groups must isolate it, and the guest must initialise it. This guide separates KVM/VFIO from Hyper-V DDA, works through each layer in order, and explains why 'not detected' and Code 43 usually point at different layers.

What Passthrough Means: One Card, One Guest, Exclusive Use

Graphics card passthrough hands an entire physical card to one virtual machine for that machine's exclusive use. While the card is passed through, the host cannot use it, and no other virtual machine can use it either. That exclusivity is the whole point of the technique — the guest gets direct access to real hardware, with performance far closer to a physical machine than virtualised graphics can offer — and it is also the source of most of its failures. Every layer between the host and the guest must agree to hand the card over, and a failure at any layer produces the same two symptoms: the guest cannot see the card, or the guest sees it but cannot start it.

This article is a troubleshooting guide organised by layer. It does not assume the reader has already decided which layer is at fault, because in passthrough work the symptom rarely identifies the layer. It also keeps two very different routes strictly separate: Linux KVM with QEMU and VFIO, and Windows Hyper-V with Discrete Device Assignment (DDA). The commands, concepts, and configuration files of one route do not transfer to the other, and mixing them is one of the most common ways a working setup is broken.

Passthrough Is Not Sharing: The Boundary to Get Right First

Before any troubleshooting, one distinction must be clear, because it determines whether passthrough is even the right technique.

Passthrough is whole-card, exclusive assignment. vGPU and SR-IOV are card-splitting techniques that require specific card firmware and driver support; they are not available on every card, and they are considerably more complex to configure. If the goal is one card shared between several virtual machines, the requirement is a vGPU or SR-IOV route, not this article's subject. If the goal is one card given entirely to one virtual machine, passthrough is the right technique, and the rest of this guide applies. Confusing the two leads to configurations that cannot work on hardware that was never designed for sharing.

The Four Conditions That Must All Hold

Passthrough works only when four conditions hold together. Troubleshooting that skips any of them will chase symptoms in the wrong layer.

First, the processor and motherboard must support IOMMU: Intel calls it VT-d, AMD calls it AMD-Vi. Support must also be enabled in the BIOS or UEFI firmware. A processor that supports IOMMU with the setting left disabled in firmware is, for practical purposes, a system without IOMMU.

Second, IOMMU groups must isolate the card cleanly. IOMMU divides PCIe devices into groups, and passthrough requires handing over a whole group. A graphics card normally shares its group with its own HDMI audio device, so the two must be passed through together. If the card shares a group with unrelated devices, such as a USB controller or a SATA controller, the whole group must be passed, or the motherboard's ACS capability must be able to split the group. A single device cannot be extracted from a group while its group-mates stay with the host.

Third, driver binding must be complete. The host's own graphics driver must release the card, and the card must be bound to the passthrough driver — vfio-pci on the Linux KVM route — before the guest can claim it. If host binding is incomplete, the guest will either not see the card at all, or see it but fail to initialise it.

Fourth, the guest must initialise the card correctly. The guest typically needs UEFI firmware (OVMF on the KVM route), a suitable PCIe topology (the Q35 machine type is the common choice on KVM), VirtIO drivers for its base devices, and the correct graphics driver installed inside the guest. An error at any of these four layers can produce the same outward symptom, which is why the diagnostic order in this guide matters more than any single fix.

Before Changing Anything: Backups and a Way Back

Changing BIOS settings, kernel parameters, or driver bindings can leave the host unable to boot. Before making any change, record the current settings: which BIOS options are changed and from what values, which kernel parameters are added, and which driver bindings are altered. Know the recovery path before it is needed — usually clearing or resetting the relevant BIOS settings to their previous values, and removing added kernel parameters from the bootloader configuration. A change without a recorded way back turns a reversible experiment into a host recovery job. Keep a second way into the host, such as integrated graphics, a second card, or remote access that does not depend on the passed-through card, because the host's display output is directly affected by what this guide changes.

Route 1: Linux KVM and QEMU with VFIO

This route is entirely separate from the Hyper-V route below. None of its steps apply to Hyper-V, and none of Hyper-V's steps apply here.

The sequence runs: enable VT-d or AMD-Vi in firmware; enable IOMMU through kernel parameters; bind the card and its audio device to vfio-pci so the host driver releases them; add the PCI host devices to the virtual machine through libvirt or virt-manager; and install the graphics driver inside the guest. Each step must be verified before moving to the next: confirm IOMMU is active, confirm the group layout, confirm the binding, and only then start the guest with the card attached.

One KVM-specific area deserves attention: hypervisor detection. Some NVIDIA guest drivers historically detect a virtualised environment and refuse to initialise the card, producing Code 43 in the guest. The common handling involves hypervisor feature settings in the guest configuration, such as hiding the KVM hypervisor signature and setting a hypervisor vendor identifier. Driver behaviour in this area changes across versions, so the correct handling must be checked against the documentation for the driver version actually in use, not assumed from older guides. Older workarounds can be unnecessary, ineffective, or counterproductive on newer drivers.

Route 2: Windows Hyper-V with Discrete Device Assignment (DDA)

Hyper-V DDA is a different mechanism with different concepts, and it must not be configured with KVM steps. Where KVM binds a device to vfio-pci and assigns it through libvirt, Hyper-V uses its own device assignment commands, its own device location paths, and its own configuration of MMIO address space for the assigned device.

MMIO space deserves specific attention on this route. A graphics card needs a large MMIO window, and an insufficient MMIO range is a common reason a Hyper-V guest fails to start once a card is assigned, or fails to see the card at all. Adjusting the MMIO range is a Hyper-V DDA configuration task with no equivalent in the KVM steps above. As with the KVM route, the diagnostic order applies: confirm the host layer first — virtualisation and IOMMU support enabled, device assignment permitted — then the assignment itself, then the guest layer. Reinstalling the guest driver before the host and assignment layers are confirmed is the most common wasted effort on both routes.

Diagnosing by Layer: Match the Symptom to the Layer

The single most useful isolation test is the guest-without-card test. If a guest with no card attached starts normally, the virtual machine itself is sound, and the problem is in passthrough. If a guest with no card attached also fails, the problem is in the virtual machine, and no amount of passthrough configuration will fix it. Running this test first separates two large classes of problem before any configuration is changed.

Code 43 in the Guest: Usually a Guest-Layer Problem

Code 43 in a guest's Device Manager — the device reported a problem and was stopped — is the most misread symptom in passthrough work. In a passthrough context, it most commonly indicates a guest driver layer issue, not a faulty card. The most well-known form is NVIDIA guest driver detection of the virtualised environment, which causes the driver to refuse to initialise the card. Driver behaviour here changes across versions: newer drivers behave differently from older ones, and any handling must be matched to the driver version actually installed, with the vendor's current documentation as the reference.

Before treating Code 43 as a driver problem, confirm two things. First, confirm the card itself is healthy on the host, using ordinary host-side diagnosis, because a card that fails on the host will also fail in the guest, and passthrough configuration cannot repair it. Second, confirm the guest firmware is UEFI rather than legacy BIOS, since guest graphics initialisation commonly depends on UEFI firmware. Only after those are confirmed does it make sense to work through hypervisor feature settings and driver version comparisons. Jumping straight to driver reinstallation while the host layer is unconfirmed is the classic wasted cycle.

The Reset Problem After a Guest Restart

A distinct symptom pattern is a card that works on the guest's first run, then cannot be used again after the guest restarts, until the whole host is restarted. This points at card reset behaviour: the card is not returning to a clean state when the guest releases it. This behaviour is associated with particular AMD models and is sometimes called the reset bug. It is a property of individual models, not of all AMD cards, and it must not be generalised. Handling varies by model and may involve model-specific workarounds; no workaround should be presented as guaranteed, and the correct approach must be judged against the specific card's documented behaviour. If a host restart reliably restores the card, the reset layer is confirmed as the problem area, and further work belongs there rather than in driver reinstallation.

When the Host Loses Its Display

A host that goes dark after a card is assigned has not necessarily broken anything. The card now belongs to the guest, so the host has no output from that card. This is expected behaviour, and it should be planned for before assignment: a second graphics card, integrated graphics, or a remote access or display-sharing solution for the host desktop. Discovering this halfway through configuration, with no way to see the host, turns a planned step into an emergency. Plan the host display path first, assign the card second.

Laptops, and Why Desktop Steps Do Not Transfer Directly

Laptop passthrough is substantially more complex than desktop passthrough. Laptop graphics switching designs, where integrated and discrete graphics share display paths, add layers that desktop steps do not address, and the display output of a passed-through laptop card may have no direct path to a screen at all. Desktop KVM or Hyper-V steps should not be applied to a laptop unchanged. Laptop configurations need their own research against the specific model's display architecture, and expectations should be set accordingly before time is spent on them.

Six Misconceptions, Corrected

"Code 43 means the card is broken." In a passthrough context, Code 43 most commonly indicates a guest driver or configuration problem. A card that works normally on the host can still show Code 43 in a guest, and the host-side check comes first.

"Enabling VT-d or AMD-Vi in firmware means IOMMU is working." Firmware enablement is only the first condition. Group layout, host driver binding, and guest firmware and configuration must also be correct; any one missing link produces the same "not detected" symptom.

"The host can keep using the card after passthrough." No. Passthrough is exclusive. While one guest holds the card, the host and every other guest cannot use it. Shared use requires a second card or a vGPU or SR-IOV route.

"All cards follow the same passthrough steps." NVIDIA and AMD guest driver behaviour differs, KVM VFIO and Hyper-V DDA steps differ, and laptop designs differ again. Steps must be matched to the route and the hardware.

"Only the graphics card itself needs to be assigned." The whole IOMMU group must be assigned, which normally includes the card's HDMI audio device. Leaving a group-mate with the host breaks isolation.

"If the guest sees the card, the hard part is over." Visibility is only the first milestone. Driver initialisation, reset behaviour across guest restarts, and display output are separate stages, each with its own failure modes.

When Inspection Is Warranted, and What to Prepare

Inspection is warranted when the card fails on the host itself, when fault symptoms persist outside any virtual machine, or when host-side diagnosis points to the card rather than configuration. Passthrough configuration problems — group layout, binding, guest firmware, driver detection — are configuration work, not hardware faults, and they cannot be resolved by inspecting a healthy card. Before seeking help, record the route used (KVM with VFIO, or Hyper-V DDA), the firmware settings changed, the IOMMU group layout, the binding state, the guest firmware type, the driver version, and the exact symptom at each layer. That record separates a configuration problem from a hardware problem before any bench work begins.

HK GPU Fix carries out in-shop inspection at Room 1209, Dali Plaza, Shek Mun, telephone 2186 8010, WhatsApp 6558 6806. Published inspection and repair pricing sits in the three-tier range of HK$400–2,800, with the actual figure quoted after inspection. For passthrough cases, bring the card with its power cables and the layer-by-layer record described above; a record that shows which layers have already been confirmed shortens diagnosis considerably.

FAQ

Is GPU passthrough the same as sharing one card between several virtual machines?

No. Passthrough assigns the whole card exclusively to one virtual machine. Sharing one card between several virtual machines is a vGPU or SR-IOV technique, which requires specific card firmware and driver support and is a different configuration task. If several virtual machines must use one card at the same time, passthrough is the wrong technique.

My guest cannot see the card at all. Where do I start?

Start at the host layer, in order: confirm IOMMU is enabled in firmware, confirm the IOMMU group layout isolates the card, and confirm the host driver has released the card and it is bound to the passthrough driver. Also run the guest-without-card test first: if a guest with no card attached also fails, the problem is in the virtual machine itself, not in passthrough.

What does Code 43 in the guest usually mean?

In a passthrough context, it most commonly means a guest driver layer problem, such as virtualisation detection by the guest driver, wrong guest firmware type, or a driver version issue. Confirm the card works on the host first, confirm the guest uses UEFI firmware, and then check the driver version's documented virtualisation behaviour before changing hypervisor settings.

Can I use the same steps for KVM and for Hyper-V?

No. KVM with VFIO and Hyper-V DDA are separate routes with different commands, concepts, and configuration, including different handling of MMIO address space on the Hyper-V route. Steps from one route must not be applied to the other.

The card works the first time, but after restarting the guest it disappears until I restart the host. What is happening?

This pattern points at card reset behaviour: the card is not returning to a clean state when the guest releases it. It is associated with particular AMD models, not all AMD cards. A host restart restoring the card confirms the reset layer as the problem area, and handling must be matched to the specific model.

Why does my host lose its display when I assign the card?

Because the card now belongs to the guest. This is expected behaviour, not damage. Plan a host display path before assignment: a second graphics card, integrated graphics, or a remote access or display-sharing solution for the host desktop.

Do I need to pass through the HDMI audio device as well?

Yes, normally. A graphics card and its HDMI audio device usually share an IOMMU group, and passthrough requires assigning the whole group. Assigning the card alone while leaving its group-mate with the host breaks the isolation the group provides.