[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 10/13] x86/Swiotlb: Add Swiotlb bounce buffer remap function for HV IVM
- To: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
- From: Tianyu Lan <ltykernel@xxxxxxxxx>
- Date: Fri, 30 Jul 2021 12:10:54 +0800
- Cc: kys@xxxxxxxxxxxxx, haiyangz@xxxxxxxxxxxxx, sthemmin@xxxxxxxxxxxxx, wei.liu@xxxxxxxxxx, decui@xxxxxxxxxxxxx, tglx@xxxxxxxxxxxxx, mingo@xxxxxxxxxx, bp@xxxxxxxxx, x86@xxxxxxxxxx, hpa@xxxxxxxxx, dave.hansen@xxxxxxxxxxxxxxx, luto@xxxxxxxxxx, peterz@xxxxxxxxxxxxx, boris.ostrovsky@xxxxxxxxxx, jgross@xxxxxxxx, sstabellini@xxxxxxxxxx, joro@xxxxxxxxxx, will@xxxxxxxxxx, davem@xxxxxxxxxxxxx, kuba@xxxxxxxxxx, jejb@xxxxxxxxxxxxx, martin.petersen@xxxxxxxxxx, arnd@xxxxxxxx, hch@xxxxxx, m.szyprowski@xxxxxxxxxxx, robin.murphy@xxxxxxx, thomas.lendacky@xxxxxxx, brijesh.singh@xxxxxxx, ardb@xxxxxxxxxx, Tianyu.Lan@xxxxxxxxxxxxx, rientjes@xxxxxxxxxx, martin.b.radev@xxxxxxxxx, akpm@xxxxxxxxxxxxxxxxxxxx, rppt@xxxxxxxxxx, kirill.shutemov@xxxxxxxxxxxxxxx, aneesh.kumar@xxxxxxxxxxxxx, krish.sadhukhan@xxxxxxxxxx, saravanand@xxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxx, pgonda@xxxxxxxxxx, david@xxxxxxxxxx, keescook@xxxxxxxxxxxx, hannes@xxxxxxxxxxx, sfr@xxxxxxxxxxxxxxxx, michael.h.kelley@xxxxxxxxxxxxx, iommu@xxxxxxxxxxxxxxxxxxxxxxxxxx, linux-arch@xxxxxxxxxxxxxxx, linux-hyperv@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, linux-scsi@xxxxxxxxxxxxxxx, netdev@xxxxxxxxxxxxxxx, vkuznets@xxxxxxxxxx, anparri@xxxxxxxxxxxxx
- Delivery-date: Fri, 30 Jul 2021 04:11:25 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
Hi Konrad:
Thanks for your review.
On 7/30/2021 12:29 AM, Konrad Rzeszutek Wilk wrote:
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 1fa81c096c1d..6866e5784b53 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -194,8 +194,13 @@ 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");
I am wondering if it would be worth returning an error code in this
function instead of just printing an error?
Yes, this is good idea and will update in the next version.
For this patch I think it is Ok, but perhaps going forward this would be
better done as I am thinking - is there some global guest->hyperv
reporting mechanism so that if this fails - it ends up being bubbled up
to the HyperV console-ish?
Hyper-V has such panic page report mechanism. Guest can pass one page
log to host during crash.
|