On 2021/3/5 2:15 下午, Yongji Xie wrote:
Sorry if I've asked this before. But what's the reason for maintaing a dedicated IOTLB here? I think we could reuse vduse_dev->iommu since the device can not be used by both virtio and vhost in the same time or use vduse_iova_domain->iotlb for set_map().The main difference between domain->iotlb and dev->iotlb is the way to deal with bounce buffer. In the domain->iotlb case, bounce buffer needs to be mapped each DMA transfer because we need to get the bounce pages by an IOVA during DMA unmapping. In the dev->iotlb case, bounce buffer only needs to be mapped once during initialization, which will be used to tell userspace how to do mmap().Also, since vhost IOTLB support per mapping token (opauqe), can we use that instead of the bounce_pages *?Sorry, I didn't get you here. Which value do you mean to store in the opaque pointer？So I would like to have a way to use a single IOTLB for manage all kinds of mappings. Two possible ideas: 1) map bounce page one by one in vduse_dev_map_page(), in VDUSE_IOTLB_GET_FD, try to merge the result if we had the same fd. Then for bounce pages, userspace still only need to map it once and we can maintain the actual mapping by storing the page or pa in the opaque field of IOTLB entry.Looks like userspace still needs to unmap the old region and map a new region (size is changed) with the fd in each VDUSE_IOTLB_GET_FD ioctl.
I don't get here. Can you give an example?
2) map bounce page once in vduse_dev_map_page() and store struct page **bounce_pages in the opaque field of this single IOTLB entry.We can get the struct page **bounce_pages from vduse_iova_domain. Why do we need to store it in the opaque field? Should the opaque field be used to store vdpa_map_file?
Oh yes, you're right.
And I think it works. One problem is we need to find a place to store the original DMA buffer's address and size. I think we can modify the array of bounce_pages for this purpose. Thanks, Yongji
Yes.
Thanks
_______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
