Dennis HilkLinux diagnosticsDE

Chipsets & PCIe

Intel VMD separate PCI domain

A table-backed Intel VMD controller profile that keeps the controller and downstream storage separate.

Editorial source review: Share public profileOpen in the identification tool
On this page
  1. Overview & identity
  2. Driver & binding
  3. Firmware
  4. Read-only diagnostics
  5. Limitations & related issues
  6. References

Overview & identity

The checked server-oriented entries carry memory-BAR shadow features, and 28c0 additionally has bus-restriction handling. The source establishes VMD controller behavior; it does not identify an exact server board or the NVMe devices behind the remapped domain.

Curated identifiers
pci 8086:201d pci 8086:28c0

A numeric match establishes a candidate family within the reviewed evidence. Marketing names, board variants, subsystem conditions and successful operation remain separate questions.

Driver & binding

vmd creates and manages a PCI hierarchy behind the controller. Storage endpoints keep their own kernel drivers, so a VMD controller and an NVMe namespace are different layers. A disk missing from an initramfs may be related to controller availability even though the NVMe driver is present; record both layers before drawing that conclusion.

  • vmd — kernel driver/module candidate

Detected, bound, operational: learn the difference

Firmware

No host payload established here

The checked VMD source defines controller features and a PCI hierarchy but no generic external firmware blob for these IDs. Platform firmware determines existing enumeration/storage policy. No host-loaded filename established here does not mean the motherboard or attached disks are firmware-free.

Inspect firmware packaging on your distribution

Read-only diagnostics

Run one displayed command at a time. Replace uppercase placeholders with the affected device, interface or module from your own output. Commands are never executed here. Read-only output can still contain private identifiers.

Read this function and its bound driver

lspci -nnk -s BDF

Replace BDF with the address of the Intel VMD separate PCI domain function. The summary normally needs no sudo. Numeric ID and the “driver in use” observation are stronger evidence than a descriptive name or candidate-module list.

Confirm the PCI driver owner

readlink /sys/bus/pci/devices/BDF/driver

Use a full domain:bus:slot.function BDF. This normally needs no sudo and only reads a symlink. The last component is the bound driver; no link records an unbound/absent function, not a missing software package.

Read the remapped PCI domains

lspci -D -t

This read-only tree normally needs no sudo. Retain domain numbers when locating controllers and downstream endpoints. A visible VMD parent is not the NVMe driver binding and is not proof that the root filesystem can be found during boot.

Read current-boot controller messages

journalctl -k -b --no-pager

Correlate VMD initialization and subsequent nvme/device discovery with the boot failure sequence. Journal access may require local group membership; failure to read it is not controller failure.

Limitations & related issues

The controller IDs do not establish RAID policy, an exact NVMe model or whether the boot image contains the required driver. No BIOS storage-mode change, unbinding, rescan or write is performed; a reported missing disk still needs its own device and boot evidence.

These guides are linked for relevant observations, not as known defects of every device in this family.

Choose a hardware diagnostic workflow · Inspect a log excerpt in Fix Lab

References

Source review records a checked implementation or document, not a reproduced hardware test. Version-specific tables do not establish a minimum kernel or guaranteed operation.