On 2021/3/5 3:13 下午, Yongji Xie wrote:
On Fri, Mar 5, 2021 at 2:52 PM Jason Wang <jasowang@xxxxxxxxxx> wrote:
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?
For example, userspace needs to process two I/O requests (one page per
request). To process the first request, userspace uses
VDUSE_IOTLB_GET_FD ioctl to query the iova region (0 ~ 4096) and mmap
it.
I think in this case we should let VDUSE_IOTLB_GET_FD return the maximum
range as far as they are backed by the same fd.
In the case of bounce page, it's bascially the whole range of bounce buffer?
Thanks
To process the second request, userspace uses VDUSE_IOTLB_GET_FD
ioctl to query the new iova region and map a new region (0 ~ 8192).
Then userspace needs to traverse the list of iova regions and unmap
the old region (0 ~ 4096). Looks like this is a little complex.
Thanks,
Yongji
