Skip to content

vfio-user: implement migration v2 (device-feature + DMA logging)#156

Draft
maxpain wants to merge 1 commit into
rust-vmm:mainfrom
maxpain:vfio-user-migration-v2
Draft

vfio-user: implement migration v2 (device-feature + DMA logging)#156
maxpain wants to merge 1 commit into
rust-vmm:mainfrom
maxpain:vfio-user-migration-v2

Conversation

@maxpain
Copy link
Copy Markdown

@maxpain maxpain commented Jun 3, 2026

Summary

This adds the vfio-user migration v2 wire protocol to the vfio-user crate, byte-compatible
with libvfio-user's include/vfio-user.h and the kernel VFIO_DEVICE_FEATURE migration uAPI. It is
the foundational piece for VMM-driven live migration of vfio-user devices — the same
VfioMigrationState semantics the kernel-VFIO path already uses, carried over the socket.

What's added

  • New commands: VFIO_USER_DEVICE_FEATURE (16), VFIO_USER_MIG_DATA_READ (17),
    VFIO_USER_MIG_DATA_WRITE (18), plus the VFIO_DEVICE_STATE_* / VFIO_DEVICE_FEATURE_* /
    VFIO_MIGRATION_* constants.
  • Server dispatch for the device-state FSM, MIG_DATA streaming (a short read marks
    end-of-stream, per the protocol), and DMA dirty logging. Wire-controlled allocations are bounded.
  • ServerBackend gains default-erroring hooks (migration_flags,
    migration_{set,get}_state, migration_{read,write}_data, dma_logging_{start,stop,report}).
    The backend owns FSM transition validity — the server forwards the requested target state to it,
    the same way vfio-ioctls does for kernel VFIO.
  • Client gains the matching methods so a VMM can drive migration.
  • An integration test driving the full FSM + MIG_DATA round-trip + DMA-logging bitmap over a
    socketpair.

Non-migratable backends are unaffected: the new commands stay rejected.

Testing

  • cargo test, cargo fmt -- --check, and cargo clippy --all-features are clean.
  • The new integration test raises workspace line coverage (~60% → ~65%), so
    coverage_config_x86_64.json is updated accordingly.

Context

This lets a VMM live-migrate a vfio-user device (e.g. an emulated NVMe controller) using the
migration-v2 model that landed for kernel VFIO. A Cloud-Hypervisor consumer
(Migratable for VfioUserPciDevice) is a follow-up that builds on this.

@maxpain maxpain marked this pull request as draft June 3, 2026 23:41
@maxpain maxpain force-pushed the vfio-user-migration-v2 branch from d4bac80 to e91f213 Compare June 3, 2026 23:47
Add the vfio-user migration v2 wire protocol, byte-compatible with
libvfio-user include/vfio-user.h:

- Command::{DeviceFeature=16, MigDataRead=17, MigDataWrite=18} and the
  VFIO_DEVICE_STATE_* / VFIO_DEVICE_FEATURE_* / VFIO_MIGRATION_* constants.
- Server dispatch for the device-state FSM, MIG_DATA streaming (a short read
  marks end-of-stream, per the spec), and DMA dirty logging; wire-controlled
  allocations are bounded.
- ServerBackend hooks (migration_flags, migration_{set,get}_state,
  migration_{read,write}_data, dma_logging_{start,stop,report}) and matching
  Client methods. The backend owns FSM transition validity; the server forwards
  the requested target state to it, as vfio-ioctls does for kernel VFIO.
- An integration test driving the FSM, MIG_DATA round-trip and DMA-logging
  bitmap over a socketpair.

Non-migratable backends are unaffected: the new commands stay rejected.

The integration test also raises workspace line coverage, so bump
coverage_config_x86_64.json accordingly.

Signed-off-by: Max Makarov <maxpain@linux.com>
Assisted-by: Claude:Opus-4.8
@maxpain maxpain force-pushed the vfio-user-migration-v2 branch from e91f213 to 5d3da4d Compare June 4, 2026 00:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant