| Message ID | 20210809175620.720923-11-ltykernel@gmail.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | x86/Hyper-V: Add Hyper-V Isolation VM support | expand |
This is still broken. You need to make sure the actual DMA allocations do have struct page backing.
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.
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@lst.de/). If there are something unclear, please let me know. Hope this still can catch the merge window. Thanks.
On Mon, Aug 16, 2021 at 10:50:26PM +0800, Tianyu Lan wrote: > 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". Do you have a git tree somewhere to look at the whole tree? > 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. Indeed. > 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@lst.de/). Well, what would help is a clear description of the semantics.
On 8/19/2021 4:49 PM, Christoph Hellwig wrote: > On Mon, Aug 16, 2021 at 10:50:26PM +0800, Tianyu Lan wrote: >> 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". > > Do you have a git tree somewhere to look at the whole tree? Yes, here is my github link for these two patches. https://github.com/lantianyu/linux/commit/462f7e4e44644fe7e182f7a5fb043a75acb90ee5 https://github.com/lantianyu/linux/commit/c8de236bf4366d39e8b98e5a091c39df29b03e0b > >> 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. > > Indeed. > >> 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@lst.de/). > > Well, what would help is a clear description of the semantics. > Yes, I will improve description.
On Thu, Aug 19, 2021 at 05:59:02PM +0800, Tianyu Lan wrote: > > > On 8/19/2021 4:49 PM, Christoph Hellwig wrote: >> On Mon, Aug 16, 2021 at 10:50:26PM +0800, Tianyu Lan wrote: >>> 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". >> >> Do you have a git tree somewhere to look at the whole tree? > > Yes, here is my github link for these two patches. > > https://github.com/lantianyu/linux/commit/462f7e4e44644fe7e182f7a5fb043a75acb90ee5 > > https://github.com/lantianyu/linux/commit/c8de236bf4366d39e8b98e5a091c39df29b03e0b Which branch is this?
On 8/19/2021 6:02 PM, Christoph Hellwig wrote: > On Thu, Aug 19, 2021 at 05:59:02PM +0800, Tianyu Lan wrote: >> >> >> On 8/19/2021 4:49 PM, Christoph Hellwig wrote: >>> On Mon, Aug 16, 2021 at 10:50:26PM +0800, Tianyu Lan wrote: >>>> 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". >>> >>> Do you have a git tree somewhere to look at the whole tree? >> >> Yes, here is my github link for these two patches. >> >> https://github.com/lantianyu/linux/commit/462f7e4e44644fe7e182f7a5fb043a75acb90ee5 >> >> https://github.com/lantianyu/linux/commit/c8de236bf4366d39e8b98e5a091c39df29b03e0b > > Which branch is this? > https://github.com/lantianyu/linux/tree/isolationv3
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h index f507e3eacbea..584560ecaa8e 100644 --- a/include/linux/swiotlb.h +++ b/include/linux/swiotlb.h @@ -72,6 +72,9 @@ extern enum swiotlb_force swiotlb_force; * @end: The end address of the swiotlb memory pool. Used to do a quick * range check to see if the memory was in fact allocated by this * API. + * @vaddr: The vaddr of the swiotlb memory pool. The swiotlb + * memory pool may be remapped in the memory encrypted case and store + * virtual address for bounce buffer operation. * @nslabs: The number of IO TLB blocks (in groups of 64) between @start and * @end. For default swiotlb, this is command line adjustable via * setup_io_tlb_npages. @@ -89,6 +92,7 @@ extern enum swiotlb_force swiotlb_force; struct io_tlb_mem { phys_addr_t start; phys_addr_t end; + void *vaddr; unsigned long nslabs; unsigned long used; unsigned int index; diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c index 1fa81c096c1d..29b6d888ef3b 100644 --- a/kernel/dma/swiotlb.c +++ b/kernel/dma/swiotlb.c @@ -176,7 +176,7 @@ void __init swiotlb_update_mem_attributes(void) memset(vaddr, 0, bytes); } -static void swiotlb_init_io_tlb_mem(struct io_tlb_mem *mem, phys_addr_t start, +static int swiotlb_init_io_tlb_mem(struct io_tlb_mem *mem, phys_addr_t start, unsigned long nslabs, bool late_alloc) { void *vaddr = phys_to_virt(start); @@ -194,14 +194,21 @@ static void swiotlb_init_io_tlb_mem(struct io_tlb_mem *mem, phys_addr_t start, mem->slots[i].alloc_size = 0; } - set_memory_decrypted((unsigned long)vaddr, bytes >> PAGE_SHIFT); - memset(vaddr, 0, bytes); + mem->vaddr = dma_map_decrypted(vaddr, bytes); + if (!mem->vaddr) { + pr_err("Failed to decrypt memory.\n"); + return -ENOMEM; + } + + memset(mem->vaddr, 0, bytes); + return 0; } int __init swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose) { struct io_tlb_mem *mem; size_t alloc_size; + int ret; if (swiotlb_force == SWIOTLB_NO_FORCE) return 0; @@ -216,7 +223,11 @@ int __init swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose) panic("%s: Failed to allocate %zu bytes align=0x%lx\n", __func__, alloc_size, PAGE_SIZE); - swiotlb_init_io_tlb_mem(mem, __pa(tlb), nslabs, false); + ret = swiotlb_init_io_tlb_mem(mem, __pa(tlb), nslabs, false); + if (ret) { + memblock_free(__pa(mem), alloc_size); + return ret; + } io_tlb_default_mem = mem; if (verbose) @@ -304,6 +315,8 @@ int swiotlb_late_init_with_tbl(char *tlb, unsigned long nslabs) { struct io_tlb_mem *mem; + int size = get_order(struct_size(mem, slots, nslabs)); + int ret; if (swiotlb_force == SWIOTLB_NO_FORCE) return 0; @@ -312,12 +325,15 @@ swiotlb_late_init_with_tbl(char *tlb, unsigned long nslabs) if (WARN_ON_ONCE(io_tlb_default_mem)) return -ENOMEM; - mem = (void *)__get_free_pages(GFP_KERNEL, - get_order(struct_size(mem, slots, nslabs))); + mem = (void *)__get_free_pages(GFP_KERNEL, size); if (!mem) return -ENOMEM; - swiotlb_init_io_tlb_mem(mem, virt_to_phys(tlb), nslabs, true); + ret = swiotlb_init_io_tlb_mem(mem, virt_to_phys(tlb), nslabs, true); + if (ret) { + free_pages((unsigned long)mem, size); + return ret; + } io_tlb_default_mem = mem; swiotlb_print_info(); @@ -360,7 +376,7 @@ static void swiotlb_bounce(struct device *dev, phys_addr_t tlb_addr, size_t size phys_addr_t orig_addr = mem->slots[index].orig_addr; size_t alloc_size = mem->slots[index].alloc_size; unsigned long pfn = PFN_DOWN(orig_addr); - unsigned char *vaddr = phys_to_virt(tlb_addr); + unsigned char *vaddr = mem->vaddr + tlb_addr - mem->start; unsigned int tlb_offset; if (orig_addr == INVALID_PHYS_ADDR)