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
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
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
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
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
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
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
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
Looks good,
Reviewed-by: Christoph Hellwig
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
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
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
Looks good,
Reviewed-by: Christoph Hellwig
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Looks good,
Reviewed-by: Christoph Hellwig
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
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
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
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
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
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
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..
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
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
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
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:"
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
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
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
@@ -
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
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
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
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
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
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
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
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
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
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
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
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
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(-
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
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
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
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
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
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
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
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
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
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
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.
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
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
> -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@
53 matches
Mail list logo