Xen PCI passthrough backend (xen-pciback)
The dom0-side stub that lets a Xen host hand a physical PCI device through to a guest virtual machine. Administrators bind a card (a NIC, GPU, storage controller, etc.) to xen-pciback so it can be reassigned to a Xen guest instead of being driven by dom0 itself.
recommendation
Worth keeping but documenting its niche, because Xen PCI passthrough is now a fairly specialized use case compared with KVM/VFIO, yet it remains a supported and actively maintained path. Upstream patches were still touching the code as recently as 2026, and current Xen toolstack documentation still tells administrators to bind devices to pciback, so removing it would break real Xen dom0 deployments with no in-tree replacement.
repository signals
sources
- lore.kernel.org
As of 2026-03-24 the driver still receives upstream maintenance; xen-pciback was updated in a PCI core cleanup series rather than a removal series.
- xenbits.xen.org
Current Xen toolstack documentation still describes making devices assignable by binding them to the pciback driver, indicating the backend remains part of supported Xen PCI passthrough workflows.
- xenbits.xen.org
Current Xen PCI configuration documentation still documents passthrough policy knobs around assignable devices, reinforcing that Xen PCI passthrough remains an active feature rather than a retired legacy path.
codex reasoning notes (technical)
Shell `rg` on the tree showed `MODULE_DESCRIPTION("Xen PCI-device stub driver")`, so this is a real driver and it is generic to Xen PCI passthrough rather than a vendor chipset. `lore_file_timeline` on the directory path returned no events, likely a directory-prefix blind spot, so I used `lore_activity(file=drivers/xen/xen-pciback/pci_stub.c)` instead; that produced a 2026 patch touching xen-pciback and suggests ongoing maintenance, with no removal evidence in the retrieved lore result. The Xen manual URLs were obtained by `web.search_query`; they show contemporary Xen docs still referring to binding devices to `pciback`, so deployments are not zero, but this is a niche Xen-dom0 passthrough role today. Because the driver is active and still documented, but serves a specialized virtualization niche and has no obvious direct in-tree replacement for Xen dom0 PCI assignment, `keep-annotate` fits better than deprecate/remove.