doca-devemu

Guides building custom emulated PCIe devices on BlueField DPUs with the DOCA Device Emulation library.

3.2k|370|Updated Feb 25, 2026
One-click install
npx skills add https://github.com/NVIDIA/skills --skill doca-devemu
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: doca-devemu
Source: https://github.com/NVIDIA/skills/tree/main/skills/doca-devemu
Command: npx skills add https://github.com/NVIDIA/skills --skill doca-devemu

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Building a custom emulated PCIe device on an NVIDIA BlueField DPU requires choosing the right DOCA Device Emulation sub-library, wiring per-sub-library Core contexts with doorbell and DMA primitives, verifying firmware-level emulation enablement, and diagnosing ambiguous DOCA_ERROR_* failures across DPU and host layers. This Skill gives an AI agent the decision rules, workflows, and error taxonomy to do that correctly.

Core Features & Use Cases

  • Sub-library selection: Routes the user to PCI Generic, virtio-net, or virtio-fs based on the emulated device class they want the host to see, and redirects packaged-service requests (DOCA SNAP, Virtio-net Service) elsewhere.
  • Six workflow verbs: Step-by-step configure, build, modify, run, test, and debug workflows covering capability queries (doca_devemu_cap), pkg-config module resolution, doorbell/DMA wiring, and host-side driver bind verification.
  • Error taxonomy and safety policy: Maps DOCA_ERROR_NOT_PERMITTED, NOT_SUPPORTED, BAD_STATE, INVALID_VALUE, and IO_FAILED to root causes across firmware, privilege, host kernel driver, and lifecycle layers.
  • Use Case: A developer asks the agent to expose a virtio-net device from a BlueField so the host sees a NIC backed by custom DPU-side packet logic; the agent walks sub-library selection, firmware precondition checks, context bring-up, and host lspci/dmesg verification.

Quick Start

Ask your agent to expose a custom emulated PCIe device from the BlueField DPU to the host using the DOCA Device Emulation library.

Frequently Asked Questions about doca-devemu

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I expose a custom PCIe device from a BlueField DPU to the host?

Use the DOCA Device Emulation library to create a per-sub-library context on the DPU against a doca_dev whose firmware has the matching emulation type enabled. After doca_ctx_start(), the host's lspci shows the emulated device and its standard kernel driver binds to it.

Which DOCA Device Emulation sub-library should I use: PCI Generic, virtio-net, or virtio-fs?

Choose PCI Generic for a custom PCIe surface with no standard virtio class, virtio-net when the host should see a standard NIC backed by your DPU packet logic, and virtio-fs for a host-visible filesystem backed by DPU-side logic. Each sub-library has its own API, pkg-config module, and capability-query family.

Should I use the doca-devemu library or the DOCA SNAP Service?

Use the doca-devemu library when you are writing your own DPU-side backend for an emulated device. Use the packaged DOCA SNAP Service or Virtio-net Service when you want a ready-made daemon without implementing the backend yourself.

Why does my doca_devemu create call return DOCA_ERROR_NOT_PERMITTED?

NOT_PERMITTED is ambiguous: it can mean missing DPU-side privilege, a disabled firmware emulation slot, a pending reset, or unsupported hardware. Verify process identity, run read-only mlxconfig current/next-boot queries, and check the exact capability getter before changing anything.

Why does lspci on the host not show my emulated device?

Missing host-side enumeration usually means the firmware emulation slot was enabled but the BlueField was not reset, or the DPU context was created against the wrong doca_dev. If the device enumerates but no driver binds, the host kernel likely lacks the matching driver module.

Can I use DOCA Device Emulation from Rust, Go, or Python?

Yes, non-C languages consume the same per-sub-library shared objects through FFI or language bindings. The sub-library selection, lifecycle, capability-discovery, and error-taxonomy rules apply unchanged, with the public C ABI as the authoritative surface.