[PATCH v4 0/6] Fixes for dma-iommu swiotlb bounce buffers

From: David Stevens This patch set includes various fixes for dma-iommu's swiotlb bounce buffers for untrusted devices. There are four fixes for correctness issues, one for a performance issue, and one for general cleanup. The min_align_mask issue was found when running fio on an untrusted nvme

[PATCH v4 1/6] dma-iommu: fix sync_sg with swiotlb

From: David Stevens The is_swiotlb_buffer function takes the physical address of the swiotlb buffer, not the physical address of the original buffer. The sglist contains the physical addresses of the original buffer, so for the sync_sg functions to work properly when a bounce buffer might have be

[PATCH v4 2/6] dma-iommu: fix arch_sync_dma for map

From: David Stevens When calling arch_sync_dma, we need to pass it the memory that's actually being used for dma. When using swiotlb bounce buffers, this is the bounce buffer. Fold __iommu_dma_map_swiotlb into iommu_dma_map_page so it can sync the right phys_addr_t. Now that iommu_dma_map_sg del

[PATCH v4 3/6] dma-iommu: skip extra sync during unmap w/swiotlb

From: David Stevens Calling the iommu_dma_sync_*_for_cpu functions during unmap can cause two copies out of the swiotlb buffer. Fold __iommu_dma_unmap_swiotlb into iommu_dma_unmap_page, and directly call arch_sync_dma_for_cpu instead of iommu_dma_sync_single_for_cpu to avoid this double sync. Wit

[PATCH v4 4/6] dma-iommu: Check CONFIG_SWIOTLB more broadly

From: David Stevens Introduce a new dev_use_swiotlb function to guard swiotlb code, instead of overloading dev_is_untrusted. This allows CONFIG_SWIOTLB to be checked more broadly, so the swiotlb related code can be removed more aggressively. Signed-off-by: David Stevens Reviewed-by: Robin Murph

[PATCH v4 5/6] swiotlb: support aligned swiotlb buffers

From: David Stevens Add an argument to swiotlb_tbl_map_single that specifies the desired alignment of the allocated buffer. This is used by dma-iommu to ensure the buffer is aligned to the iova granule size when using swiotlb with untrusted sub-granule mappings. This addresses an issue where adja

[PATCH v4 6/6] dma-iommu: account for min_align_mask

From: David Stevens For devices which set min_align_mask, swiotlb preserves the offset of the original physical address within that mask. Since __iommu_dma_map accounts for non-aligned addresses, passing a non-aligned swiotlb address with the swiotlb aligned size results in the offset being accou

Re: An cma optimization patch is used for cma_[alloc|free].

On 13.08.21 09:00, Jichao Zou wrote: Pre-allocate CMA memory that configured in device tree, this greatly improves the CMA memory allocation efficiency, cma_[alloc|free] is less than 1ms, old way is took a few ms to tens or hundreds ms. Please send patches as proper emails (man git-format-patc

Re: [PATCH v4 1/6] dma-iommu: fix sync_sg with swiotlb

Looks good, Reviewed-by: Christoph Hellwig ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v4 2/6] dma-iommu: fix arch_sync_dma for map

I have a really hard time reading following the patch. Can you split folding__iommu_dma_map_swiotlb into iommu_dma_map_page into a second cleanup patch? ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/list

Re: [PATCH v4 3/6] dma-iommu: skip extra sync during unmap w/swiotlb

Same comment as for the previous one - please split the actual bug fix from the code movement. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v4 4/6] dma-iommu: Check CONFIG_SWIOTLB more broadly

Looks good, Reviewed-by: Christoph Hellwig ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v4 5/6] swiotlb: support aligned swiotlb buffers

Looks good, Reviewed-by: Christoph Hellwig ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

An cma optimization patch is used for cma_[alloc|free].

Pre-allocate CMA memory that configured in device tree, this greatly improves the CMA memory allocation efficiency, cma_[alloc|free] is less than 1ms, old way is took a few ms to tens or hundreds ms. Thanks. Best Regards, Zou Jichao 邹纪超 Advisory Engineer, SW BSP MBG ROW SW BJ PF BSP (CN) Motorol

回复: [External]Re: An cma optimization patch is used for cma_[alloc|free].

Hi David, I'll git-send-email patch again. Your understanding is exactly right. Let me explain the background of Patch, we are developing Android phone, kernel is 5.10.43 LTS, we encounter cma_alloc failed during kernel startup, buddy system is ready, 01-11 14:22:08.650

Re: 回复: [External]Re: An cma optimization patch is used for cma_[alloc|free].

On 2021-08-13 09:27, Jichao Zou wrote: Hi David, I'll git-send-email patch again. Your understanding is exactly right. Let me explain the background of Patch, we are developing Android phone, kernel is 5.10.43 LTS, we encounter cma_alloc failed during kernel startup, bud

回复: 回复: [External]Re: An cma optimization patch is used for cma_[alloc|free].

I got it, but in kernel that we used version, many heap drivers that in drivers/dma-buf/ are based on CMA, not DMA carveout! If this patch is not accepted, we cancel it!!! Thank you all. Best Regards, -邮件原件- 发件人: Robin Murphy 发送时间: 2021年8月13日 17:16 收件人: Jichao Zou ; David Hildenbrand

Re: 回复: 回复: [External]Re: An cma optimization patch is used for cma_[alloc|free].

On 2021-08-13 10:46, Jichao Zou wrote: I got it, but in kernel that we used version, many heap drivers that in drivers/dma-buf/ are based on CMA, not DMA carveout! If this patch is not accepted, we cancel it!!! If you just want dma_alloc_coherent() to work automatically from a carveout in the

回复: 回复: 回复: [External]Re: An cma optimization patch is used for cma_[alloc|free].

Hi Robin, David Thank you for your guidance very much, we'll go ahead and see if some heap drivers can use carveout heap instead. Thanks. Best Regards, -邮件原件- 发件人: Robin Murphy 发送时间: 2021年8月13日 18:08 收件人: Jichao Zou ; David Hildenbrand ; a...@linux-foundation.org; linux-ker..

Re: [PATCH] iommu/arm-smmu-v3: Stop pre-zeroing batch commands

On Wed, 11 Aug 2021 23:49:26 +0800, John Garry wrote: > Pre-zeroing the batched commands structure is inefficient, as individual > commands are zeroed later in arm_smmu_cmdq_build_cmd(). The size is quite > large and commonly most commands won't even be used: > > struct arm_smmu_cmdq_batch c

Re: [PATCHv5] iommu/arm-smmu: Optimize ->tlb_flush_walk() for qcom implementation

On Wed, 11 Aug 2021 21:34:26 +0530, Sai Prakash Ranjan wrote: > Currently for iommu_unmap() of large scatter-gather list with page size > elements, the majority of time is spent in flushing of partial walks in > __arm_lpae_unmap() which is a VA based TLB invalidation invalidating > page-by-page on

Re: [PATCH 0/4] Prepare for ECMDQ support

On Wed, 11 Aug 2021 19:48:48 +0800, Zhen Lei wrote: > RFC --> v1 > 1. Resend the patches for ECMDQ preparation and remove the patches for ECMDQ > implementation. > 2. Patch 2 is modified. Other patches remain unchanged. >1) Add static helper __arm_smmu_cmdq_issue_cmd(), and make > arm_smmu_cm

Re: [PATCH V3 01/13] x86/HV: Initialize GHCB page in Isolation VM

Hi Michael: Thanks for your review. On 8/13/2021 3:14 AM, Michael Kelley wrote: From: Tianyu Lan Sent: Monday, August 9, 2021 10:56 AM Subject: [PATCH V3 01/13] x86/HV: Initialize GHCB page in Isolation VM The subject line tag on patches under arch/x86/hyperv is generally "x86/hyperv:"

Re: [PATCH 1/4] iommu/arm-smmu-v3: Use command queue batching helpers to improve performance

On 2021-08-11 12:48, Zhen Lei wrote: The obvious key to the performance optimization of commit 587e6c10a7ce ("iommu/arm-smmu-v3: Reduce contention during command-queue insertion") is to allow multiple cores to insert commands in parallel after a brief mutex contention. Obviously, inserting as ma

Re: [Resend RFC PATCH V4 09/13] x86/Swiotlb/HV: Add Swiotlb bounce buffer remap function for HV IVM

Hi Christoph: I followed your this suggestion to rework the latest version(https://lkml.org/lkml/2021/8/9/805). I just remove the arch prefix from your suggested name arch_dma_map_decrypted because the platform may populate their map/umap callback in the ops. But from your latest comment(h

Re: [PATCH 1/4] iommu/arm-smmu-v3: Use command queue batching helpers to improve performance

On 13/08/2021 17:01, Robin Murphy wrote: diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c index 235f9bdaeaf223b..c81cd929047f573 100644 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c @@ -

[GIT PULL] iommu/arm-smmu: Updates for 5.15

Hi Joerg, Please pull these Arm SMMU updates for 5.15. There's not tonnes here, but a good mixture of optimisations and cleanups -- summary in the tag. This applies cleanly against iommu/next, but I suspect it will conflict with Robin's series on the list. Please shout if you need anything from m

Re: [PATCH] powerpc/svm: Don't issue ultracalls if !mem_encrypt_active()

On Mon, Aug 02, 2021 at 09:20:30PM +1000, Michael Ellerman wrote: > Will Deacon writes: > > Commit ad6c00283163 ("swiotlb: Free tbl memory in swiotlb_exit()") > > introduced a set_memory_encrypted() call to swiotlb_exit() so that the > > buffer pages are returned to an encrypted state prior to bei

[PATCH v2 00/12] Implement generic prot_guest_has() helper function

This patch series provides a generic helper function, prot_guest_has(), to replace the sme_active(), sev_active(), sev_es_active() and mem_encrypt_active() functions. It is expected that as new protected virtualization technologies are added to the kernel, they can all be covered by a single funct

[PATCH v2 01/12] x86/ioremap: Selectively build arch override encryption functions

In prep for other uses of the prot_guest_has() function besides AMD's memory encryption support, selectively build the AMD memory encryption architecture override functions only when CONFIG_AMD_MEM_ENCRYPT=y. These functions are: - early_memremap_pgprot_adjust() - arch_memremap_can_ram_remap() Add

[PATCH v2 02/12] mm: Introduce a function to check for virtualization protection features

In prep for other protected virtualization technologies, introduce a generic helper function, prot_guest_has(), that can be used to check for specific protection attributes, like memory encryption. This is intended to eliminate having to add multiple technology-specific checks to the code (e.g. if

[PATCH v2 03/12] x86/sev: Add an x86 version of prot_guest_has()

Introduce an x86 version of the prot_guest_has() function. This will be used in the more generic x86 code to replace vendor specific calls like sev_active(), etc. While the name suggests this is intended mainly for guests, it will also be used for host memory encryption checks in place of sme_acti

[PATCH v2 04/12] powerpc/pseries/svm: Add a powerpc version of prot_guest_has()

Introduce a powerpc version of the prot_guest_has() function. This will be used to replace the powerpc mem_encrypt_active() implementation, so the implementation will initially only support the PATTR_MEM_ENCRYPT attribute. Cc: Michael Ellerman Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Signe

[PATCH v2 05/12] x86/sme: Replace occurrences of sme_active() with prot_guest_has()

Replace occurrences of sme_active() with the more generic prot_guest_has() using PATTR_HOST_MEM_ENCRYPT, except for in arch/x86/mm/mem_encrypt*.c where PATTR_SME will be used. If future support is added for other memory encryption technologies, the use of PATTR_HOST_MEM_ENCRYPT can be updated, as r

[PATCH v2 06/12] x86/sev: Replace occurrences of sev_active() with prot_guest_has()

Replace occurrences of sev_active() with the more generic prot_guest_has() using PATTR_GUEST_MEM_ENCRYPT, except for in arch/x86/mm/mem_encrypt*.c where PATTR_SEV will be used. If future support is added for other memory encryption technologies, the use of PATTR_GUEST_MEM_ENCRYPT can be updated, as

[PATCH v2 07/12] x86/sev: Replace occurrences of sev_es_active() with prot_guest_has()

Replace occurrences of sev_es_active() with the more generic prot_guest_has() using PATTR_GUEST_PROT_STATE, except for in arch/x86/kernel/sev*.c and arch/x86/mm/mem_encrypt*.c where PATTR_SEV_ES will be used. If future support is added for other memory encyrption techonologies, the use of PATTR_GUE

[PATCH v2 08/12] treewide: Replace the use of mem_encrypt_active() with prot_guest_has()

Replace occurrences of mem_encrypt_active() with calls to prot_guest_has() with the PATTR_MEM_ENCRYPT attribute. Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: Dave Hansen Cc: Andy Lutomirski Cc: Peter Zijlstra Cc: David Airlie Cc: Daniel Vetter Cc: Maarten Lankhorst Cc: Maxi

[PATCH v2 09/12] mm: Remove the now unused mem_encrypt_active() function

The mem_encrypt_active() function has been replaced by prot_guest_has(), so remove the implementation. Reviewed-by: Joerg Roedel Signed-off-by: Tom Lendacky --- include/linux/mem_encrypt.h | 4 1 file changed, 4 deletions(-) diff --git a/include/linux/mem_encrypt.h b/include/linux/mem_enc

[PATCH v2 10/12] x86/sev: Remove the now unused mem_encrypt_active() function

The mem_encrypt_active() function has been replaced by prot_guest_has(), so remove the implementation. Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Reviewed-by: Joerg Roedel Signed-off-by: Tom Lendacky --- arch/x86/include/asm/mem_encrypt.h | 5 - 1 file changed, 5 deletions(-

[PATCH v2 11/12] powerpc/pseries/svm: Remove the now unused mem_encrypt_active() function

The mem_encrypt_active() function has been replaced by prot_guest_has(), so remove the implementation. Cc: Michael Ellerman Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Signed-off-by: Tom Lendacky --- arch/powerpc/include/asm/mem_encrypt.h | 5 - 1 file changed, 5 deletions(-) diff --gi

[PATCH v2 12/12] s390/mm: Remove the now unused mem_encrypt_active() function

The mem_encrypt_active() function has been replaced by prot_guest_has(), so remove the implementation. Since the default implementation of the prot_guest_has() matches the s390 implementation of mem_encrypt_active(), prot_guest_has() does not need to be implemented in s390 (the config option ARCH_H

Re: [GIT PULL] iommu/arm-smmu: Updates for 5.15

On 2021-08-13 17:47, Will Deacon wrote: Hi Joerg, Please pull these Arm SMMU updates for 5.15. There's not tonnes here, but a good mixture of optimisations and cleanups -- summary in the tag. This applies cleanly against iommu/next, but I suspect it will conflict with Robin's series on the list

Re: [PATCH 07/11] treewide: Replace the use of mem_encrypt_active() with prot_guest_has()

On 8/12/21 5:07 AM, Kirill A. Shutemov wrote: On Wed, Aug 11, 2021 at 10:52:55AM -0500, Tom Lendacky wrote: On 8/11/21 7:19 AM, Kirill A. Shutemov wrote: On Tue, Aug 10, 2021 at 02:48:54PM -0500, Tom Lendacky wrote: On 8/10/21 1:45 PM, Kuppuswamy, Sathyanarayanan wrote: ... Looking at code a

Re: [PATCH v2 02/12] mm: Introduce a function to check for virtualization protection features

On 8/13/21 9:59 AM, Tom Lendacky wrote: In prep for other protected virtualization technologies, introduce a generic helper function, prot_guest_has(), that can be used to check for specific protection attributes, like memory encryption. This is intended to eliminate having to add multiple tec

Re: [PATCH v2 00/12] Implement generic prot_guest_has() helper function

On 8/13/21 11:59 AM, Tom Lendacky wrote: This patch series provides a generic helper function, prot_guest_has(), to replace the sme_active(), sev_active(), sev_es_active() and mem_encrypt_active() functions. It is expected that as new protected virtualization technologies are added to the kernel

Re: [PATCH V3 10/13] x86/Swiotlb: Add Swiotlb bounce buffer remap function for HV IVM

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 memo

[PATCH] iommu/vt-d: Fix PASID reference leak

A PASID reference is increased whenever a device is bound to an mm (and its PASID) successfully (i.e. the device's sdev user count is increased). But the reference is not dropped every time the device is unbound successfully from the mm (i.e. the device's sdev user count is decreased). The referenc

RE: [PATCH V3 05/13] HV: Add Write/Read MSR registers via ghcb page

From: Tianyu Lan Sent: Monday, August 9, 2021 10:56 AM > Subject: [PATCH V3 05/13] HV: Add Write/Read MSR registers via ghcb page See previous comments about tag in the Subject line. > Hyper-V provides GHCB protocol to write Synthetic Interrupt > Controller MSR registers in Isolation VM with AMD

Re: [PATCH 07/11] treewide: Replace the use of mem_encrypt_active() with prot_guest_has()

On 8/13/21 12:08 PM, Tom Lendacky wrote: On 8/12/21 5:07 AM, Kirill A. Shutemov wrote: On Wed, Aug 11, 2021 at 10:52:55AM -0500, Tom Lendacky wrote: On 8/11/21 7:19 AM, Kirill A. Shutemov wrote: On Tue, Aug 10, 2021 at 02:48:54PM -0500, Tom Lendacky wrote: On 8/10/21 1:45 PM, Kuppuswamy, Sath

RE: [PATCH V3 05/13] HV: Add Write/Read MSR registers via ghcb page

From: Michael Kelley Sent: Friday, August 13, 2021 12:31 PM > To: Tianyu Lan ; KY Srinivasan ; > Haiyang Zhang ; > Stephen Hemminger ; wei@kernel.org; Dexuan Cui > ; > t...@linutronix.de; mi...@redhat.com; b...@alien8.de; x...@kernel.org; > h...@zytor.com; dave.han...@linux.intel.com; > l.

RE: [PATCH V3 06/13] HV: Add ghcb hvcall support for SNP VM

From: Tianyu Lan Sent: Monday, August 9, 2021 10:56 AM > > Hyper-V provides ghcb hvcall to handle VMBus > HVCALL_SIGNAL_EVENT and HVCALL_POST_MESSAGE > msg in SNP Isolation VM. Add such support. > > Signed-off-by: Tianyu Lan > --- > arch/x86/hyperv/ivm.c | 43

RE: [PATCH V3 07/13] HV/Vmbus: Add SNP support for VMbus channel initiate message

From: Tianyu Lan Sent: Monday, August 9, 2021 10:56 AM > > The monitor pages in the CHANNELMSG_INITIATE_CONTACT msg are shared > with host in Isolation VM and so it's necessary to use hvcall to set > them visible to host. In Isolation VM with AMD SEV SNP, the access > address should be in the ext

RE: [PATCH 7/7] hexagon: use the generic global coherent pool

> -Original Message- > From: Christoph Hellwig ... > Switch hexagon to use the generic code for dma_alloc_coherent from > a global pre-filled pool. > > Signed-off-by: Christoph Hellwig Reviewed-by: Brian Cain ___ iommu mailing list iommu@