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