On 8/14/2021 1:58 AM, Tianyu Lan wrote:
On 8/12/2021 8:27 PM, Christoph Hellwig wrote:
This is still broken. You need to make sure the actual DMA allocations
do have struct page backing.
Hi Christoph:
swiotlb_tbl_map_single() still returns PA below vTOM/share_gpa_ > boundary. These PAs has backing pages and belong to system memory.
In other word, all PAs passed to DMA API have backing pages and these is
no difference between Isolation guest and traditional guest for DMA API.
The new mapped VA for PA above vTOM here is just to access the bounce
buffer in the swiotlb code and isn't exposed to outside.
Hi Christoph:
Sorry to bother you.Please double check with these two patches
" [PATCH V3 10/13] x86/Swiotlb: Add Swiotlb bounce buffer remap function
for HV IVM" and "[PATCH V3 09/13] DMA: Add dma_map_decrypted/dma_
unmap_encrypted() function".
The swiotlb bounce buffer in the isolation VM are allocated in the
low end memory and these memory has struct page backing. All dma address
returned by swiotlb/DMA API are low end memory and this is as same as
what happen in the traditional VM.So this means all PAs passed to DMA
API have struct page backing. The difference in Isolation VM is to
access bounce buffer via address space above vTOM/shared_guest_memory
_boundary. To access bounce buffer shared with host, the guest needs to
mark the memory visible to host via hypercall and map bounce buffer in
the extra address space(PA + shared_guest_memory_boundary). The vstart
introduced in this patch is to store va of extra address space and it's
only used to access bounce buffer in the swiotlb_bounce(). The PA in
extra space is only in the Hyper-V map function and won't be passed to
DMA API or other components.
The API dma_map_decrypted() introduced in the patch 9 is to map
the bounce buffer in the extra space and these memory in the low end
space are used as DMA memory in the driver. Do you prefer these APIs
still in the set_memory.c? I move the API to dma/mapping.c due to the
suggested name arch_dma_map_decrypted() in the previous mail
(https://lore.kernel.org/netdev/20210720135437.GA13554@xxxxxx/).
If there are something unclear, please let me know. Hope this
still can catch the merge window.
Thanks.
