On 11/26/2021 3:40 PM, Christoph Hellwig wrote:
On Wed, Nov 17, 2021 at 10:00:08PM +0800, Tianyu Lan wrote:
On 11/17/2021 6:01 PM, Christoph Hellwig wrote:
This doesn't really have much to do with normal DMA mapping,
so why does this direct through the dma ops?
According to the previous discussion, dma_alloc_noncontigous()
and dma_vmap_noncontiguous() may be used to handle the noncontigous
memory alloc/map in the netvsc driver. So add alloc/free and vmap/vunmap
callbacks here to handle the case. The previous patch v4 & v5 handles
the allocation and map in the netvsc driver. If this should not go though
dma ops, We also may make it as vmbus specific function and keep
the function in the vmbus driver.
But that only makes sense if they can actually use the normal DMA ops.
If you implement your own incomplete ops and require to use them you
do nothing but adding indirect calls to your fast path and making the
code convoluted.
Because the generic part implementation can't meet the netvsc driver
requests that allocate 16M memory and map pages via vmap_pfn(). So add
Hyperv alloc_noncontiguous and vmap_noncontiguous callbacks. If this is
not a right way. we should call these hyper-V functions in the netvsc
driver directly, right?
Could you have a look at Michael summary about this series we made and
give some guides?
https://www.mail-archive.com/xen-devel@xxxxxxxxxxxxxxxxxxxx/msg109284.html
Thanks.
