On Tue, Aug 24, 2021 at 06:24:27PM +0200, David Hildenbrand wrote: > > > Not so much; here's the list of priorities and the devices using it: > > > > > > |--------------------+---------| > > > | priority | devices | > > > |--------------------+---------| > > > | MIG_PRI_IOMMU | 3 | > > > | MIG_PRI_PCI_BUS | 7 | > > > | MIG_PRI_VIRTIO_MEM | 1 | > > > | MIG_PRI_GICV3_ITS | 1 | > > > | MIG_PRI_GICV3 | 1 | > > > |--------------------+---------| > > > > iommu is probably ok. I think virtio mem is ok too, > > in that it is normally created by virtio-mem-pci ... > > IIRC: > > intel-iommu has to be created on the QEMU cmdline before creating > virtio-mem-pci. > > -device intel-iommu,caching-mode=on,intremap=on,device-iotlb=on \ > ... > -device > virtio-mem-pci,disable-legacy=on,disable-modern=off,iommu_platform=on,ats=on,id=vm0,... > > Creating virtio-mem-pci will implicitly create virtio-mem. virtio-mem device > state has to be migrated before migrating intel-iommu state.
Since we're at it.. frankly I didn't fully digest why virtio-mem needs to be migrated before when reading commit 0fd7616e0f1171b. It gives me the feeling more like that virtio-mem has a ordering dependency with vfio-pci not virtio-mem, but I could be wrong. E.g., the IOMMU unit shouldn't be walking page table if without a device using it, then it won't fail until the device walks it in region_add() hooks when memory replay happens. > > I do wonder if migration priorities are really what we want to reuse here. I > guess it works right, but just by pure luck (because we ignore the implicit > dependency regarding priorities) Yep, that's probably not what we want. I'll make it a new list of priorities as I've stated in the other thread. Thanks, -- Peter Xu
