On Thu, Nov 2, 2023 at 8:38 PM Eugenio Perez Martin <epere...@redhat.com> wrote: > > On Thu, Nov 2, 2023 at 11:13 AM Si-Wei Liu <si-wei....@oracle.com> wrote: > > > > > > > > On 10/19/2023 7:34 AM, Eugenio Pérez wrote: > > > Current memory operations like pinning may take a lot of time at the > > > > > > destination. Currently they are done after the source of the migration is > > > > > > stopped, and before the workload is resumed at the destination. This is a > > > > > > period where neigher traffic can flow, nor the VM workload can continue > > > > > > (downtime). > > > > > > > > > > > > We can do better as we know the memory layout of the guest RAM at the > > > > > > destination from the moment the migration starts. Moving that operation > > > allows > > > > > > QEMU to communicate the kernel the maps while the workload is still > > > running in > > > > > > the source, so Linux can start mapping them. Ideally, all IOMMU is > > > configured, > > > > > > but if the vDPA parent driver uses on-chip IOMMU and .set_map we're still > > > > > > saving all the pinning time. > > I get what you want to say, though not sure how pinning is relevant to > > on-chip IOMMU and .set_map here, essentially pinning is required for all > > parent vdpa drivers that perform DMA hence don't want VM pages to move > > around. > > Basically highlighting that the work done under .set_map is not only > pinning, but it is a significant fraction on it. It can be reworded or > deleted for sure. > > > > > > > > > > > > > Note that further devices setup at the end of the migration may alter the > > > guest > > > > > > memory layout. But same as the previous point, many operations are still > > > done > > > > > > incrementally, like memory pinning, so we're saving time anyway. > > > > > > > > > > > > The first bunch of patches just reorganizes the code, so memory related > > > > > > operation parameters are shared between all vhost_vdpa devices. This is > > > > > > because the destination does not know what vhost_vdpa struct will have the > > > > > > registered listener member, so it is easier to place them in a shared > > > struct > > > > > > rather to keep them in vhost_vdpa struct. Future version may squash or > > > omit > > > > > > these patches. > > It looks this VhostVDPAShared facility (patch 1-13) is also what I need > > in my SVQ descriptor group series [*], for which I've built similar > > construct there. If possible please try to merge this in ASAP. I'll > > rework my series on top of that. > > > > [*] > > https://github.com/siwliu-kernel/qemu/commit/813518354af5ee8a6e867b2bf7dff3d6004fbcd5 > > > > I can send it individually, for sure. > > MST, Jason, can this first part be merged? It doesn't add a lot by > itself but it helps pave the way for future changes. >
I'm fine with that, or it might be easier if you resend it as a standalone series. Thanks
