mirror of
https://github.com/cloud-hypervisor/cloud-hypervisor.git
synced 2026-08-05 02:19:16 +00:00
4102768561
When a snapshot is loaded, walk the migration v2 state machine from VfioCommon::set_state() after interrupt state has been restored. If the device supports migration and a blob is present, drive RUNNING to RESUMING in a single transition and write the blob to the data_fd. The kernel handles the intermediate STOP arc internally. An explicit STOP dwell was observed to make mlx5_vfio_pci re initialize SQ, CQ, and EQ indices on top of the just loaded blob, wedging queue state on resume. The device is left in RESUMING and resume() drives it to RUNNING during VM resume. set_state() also pushes PCI_COMMAND to the device via write_config() after the blob load. Rebuilding the in memory MSI or MSI-X structs does not touch the kernel's view of PCI_COMMAND, so without this the VF sits at post reset defaults with no bus master and mlx5_core ACCESS_REG times out. It rearms VFIO_DEVICE_SET_IRQS via enable_msi or enable_msix for the same reason, since replaying the in memory interrupt state does not reissue the ioctl and the kernel has no eventfds for this device until it does. Both match QEMU vfio_pci_load_config(). In allocate_bars, skip add_pci_bar and add_pci_rom_bar on restore. PciConfiguration::new(Some(state)) already populated the BAR registers with used=true, so the extra call trips BarInUse. The bars vec and mmio_regions pushes still need to happen so the caller can wire bus mappings. set_state() retrieves the migration blob from the snapshot unconditionally and rejects a snapshot that carries migration state when the device does not support migration, rather than silently dropping the saved state. A device without migration support and no blob, including vfio-user, still skips the load. On any transition or write failure during restore, STOP is attempted as best effort before bubbling the error. Signed-off-by: Saravanan D <saravanand@crusoe.ai>