On 10/12/2023 8:04 PM, Jason Wang wrote:
On Tue, Oct 10, 2023 at 5:05 PM Si-Wei Liu <si-wei.liu@xxxxxxxxxx> wrote:
Since commit 6f5312f80183 ("vdpa/mlx5: Add support for running with
virtio_vdpa"), mlx5_vdpa starts with preallocate 1:1 DMA MR at device
creation time. This 1:1 DMA MR will be implicitly destroyed while
the first .set_map call is invoked, in which case callers like
vhost-vdpa will start to set up custom mappings. When the .reset
callback is invoked, the custom mappings will be cleared and the 1:1
DMA MR will be re-created.
In order to reduce excessive memory mapping cost in live migration,
it is desirable to decouple the vhost-vdpa IOTLB abstraction from
the virtio device life cycle, i.e. mappings can be kept around intact
across virtio device reset. Leverage the .reset_map callback, which
is meant to destroy the regular MR on the given ASID and recreate the
initial DMA mapping. That way, the device .reset op can run free from
having to maintain and clean up memory mappings by itself.
The cvq mapping also needs to be cleared if is in the given ASID.
Co-developed-by: Dragos Tatulea <dtatulea@xxxxxxxxxx>
Signed-off-by: Dragos Tatulea <dtatulea@xxxxxxxxxx>
Signed-off-by: Si-Wei Liu <si-wei.liu@xxxxxxxxxx>
I wonder if the simulator suffers from the exact same issue.
For vdpa-sim !use_va (map using PA and with pinning) case, yes. But I'm
not sure the situation of the vdpa-sim(-blk) use_va case, e.g. I haven't
checked if there's dependency on today's reset behavior (coupled), and
if QEMU vhost-vdpa backend driver is the only userspace consumer. Maybe
Stefano knows?
I can give it a try on simulator fix but don't count me on the
vdpa-sim(-blk) use_va part.
Regards,
-Siwei
If yes,
let's fix the simulator as well?
Thanks
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
