Thanks to visit codestin.com
Credit goes to github.com

Skip to content

pci: synchronize VfioMsix::cap and VfioMsix::bar - #7993

Merged
rbradford merged 1 commit into
cloud-hypervisor:mainfrom
googleprodkernel:fix/vfio/msix-cap-msg-ctrl
Apr 11, 2026
Merged

rbradford merged 1 commit into
cloud-hypervisor:mainfrom
googleprodkernel:fix/vfio/msix-cap-msg-ctrl

Conversation

@Lencerf

@Lencerf Lencerf commented Apr 10, 2026

Copy link
Copy Markdown
Contributor

Currently, when snapshoting a running VFIO device with MSI-X enabled, we get a snapshot where msix_config.state.enabled is not consistent with msix_state.cap.msg_ctl,

{
  "snapshots": {
    "vfio_common": {
      "snapshots": {
        "msix_config": {
          "snapshots": {},
          "state": {
            "enabled": true
            // ...
          }
        },
        // ..
      },
      "state": {
        "msix_state": {
          "cap": {
            "msg_ctl": 3,
            "table": 1,
            "pba": 2049
          },
          // ...
        }
        // ...
      }
    }
  },
  // ...
}

The root cause is, after a MsixCap is parsed from the device PCI config space and propagated to a corresponding MsixConfig, MsixCap::msg_ctl is never get updated at runtime, only MsixConfig::msg_ctl is updated.

This commit makes VfioMsix::update update both VfioMsix::bar (of type MsixConfig) and VfioMsix::cap (of type MsixCap).

Currently, when snapshoting a running VFIO device with MSI-X enabled,
we get a snapshot where `msix_config.state.enabled` is not consistent
with `msix_state.cap.msg_ctl`,

```jsonc
{
  "snapshots": {
    "vfio_common": {
      "snapshots": {
        "msix_config": {
          "snapshots": {},
          "state": {
            "enabled": true
            // ...
          }
        },
        // ..
      },
      "state": {
        "msix_state": {
          "cap": {
            "msg_ctl": 3,
            "table": 1,
            "pba": 2049
          },
          // ...
        }
        // ...
      }
    }
  },
  // ...
}
```

The root cause is, after a `MsixCap` is parsed from the device PCI
config space and propagated to a corresponding `MsixConfig`,
`MsixCap::msg_ctl` is never get updated at runtime, only
`MsixConfig::msg_ctl` is updated.

This commit makes `VfioMsix::update` update both `VfioMsix::bar` (of
type `MsixConfig`) and `VfioMsix::cap` (of type `MsixCap`).

Signed-off-by: Changyuan Lyu <[email protected]>
@Lencerf
Lencerf requested a review from a team as a code owner April 10, 2026 19:32

@likebreath likebreath left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Lencerf Thanks for the contribution. The fix looks good.

Likely you know, the snapshot/restore for VFIO devices isn't fully functional, since it currently only covers VMM-side state. Restoring the physical device state still requires additional work, specifically implementing parts of the VFIO live migration V2 protocol. Is this something you're planning to work on?

I mention this because @saravan2 will be starting work on VFIO live migration support soon, so there may be a good opportunity to collaborate.

@likebreath
likebreath added this pull request to the merge queue Apr 10, 2026
@github-merge-queue
github-merge-queue Bot removed this pull request from the merge queue due to failed status checks Apr 11, 2026
@likebreath

Copy link
Copy Markdown
Member

Unrelated flaky CI failure: https://github.com/cloud-hypervisor/cloud-hypervisor/actions/runs/24269673912/job/70871907846

TIMEOUT [ 600.015s] (7/7) cloud-hypervisor::integration windows::test_windows_guest_snapshot_restore

@likebreath
likebreath added this pull request to the merge queue Apr 11, 2026
@github-merge-queue
github-merge-queue Bot removed this pull request from the merge queue due to failed status checks Apr 11, 2026
@likebreath
likebreath added this pull request to the merge queue Apr 11, 2026
@github-merge-queue
github-merge-queue Bot removed this pull request from the merge queue due to failed status checks Apr 11, 2026
@rbradford
rbradford added this pull request to the merge queue Apr 11, 2026
Merged via the queue into cloud-hypervisor:main with commit 490e338 Apr 11, 2026
38 checks passed
@Lencerf

Lencerf commented Apr 13, 2026

Copy link
Copy Markdown
Contributor Author

Restoring the physical device state still requires additional work, specifically implementing parts of the VFIO live migration V2 protocol. Is this something you're planning to work on?

Hi @likebreath , instead of restoring the physical device state, we (@posk-io and I) are more interested in keeping the device running during snapshot and restore. To give an example, say we have a physical GPU assigned to a VM and is running training workloads, and we want to update cloud-hypervisor or KVM module due to some emergent security bug.

  1. To upgrade cloud-hypervisor, we let cloud-hypervisor transfer VFIO device/group/container FDs to another helper process, and then snapshot, shutdown, and restore the VM with a patched cloud-hypervisor. In the restore path, cloud-hypervisor re-constructs its internal states by acquiring the VFIO device/group/container FDs from the helper process, instead of re-opening /dev/vfio/XXX.
  2. To upgrade KVM, we will use Linux kernel Live Update Orchestrator(still under active development in upstream community). The idea is similar to upgrading cloud-hypervisor, but the VFIO device/group/container FDs, as well as VM memory, device IO page tables, etc, will be kept by LUO during host kernel kexec.

We will gradually upstreaming the live update support described above to cloud-hypervisor.

@saravan2

Copy link
Copy Markdown
Member

@Lencerf I am working on adding VFIO migration v2 protocol support. Feel free to reach out if you think collaborating can speed up development. I am currently working on a PR to rust-vmm/vfio to add VFIO_DEVICE_FEATURE ioctl definition and operation methods.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: ✅ Done

Development

Successfully merging this pull request may close these issues.

4 participants