Hi Jason,
On Mon, 10 May 2021 13:39:56 -0300, Jason Gunthorpe wrote:
> I still think it is smarter to push a group of RID's into a global
> allocation group and accept there are potential downsides with that
> than to try to force a global allocation group on every RID and then
> try to fix the
On Mon, May 10, 2021 at 03:28:54PM -0700, Jacob Pan wrote:
> To satisfy your "give me a PASID for this RID" proposal, can we just use
> the RID's struct device as the token? Also add a type field to explicitly
> indicate global vs per-set(per-RID). i.e.
You've got it backwards, the main behavior
A couple of small changes to simplify and restrict SVA APIs. The motivation
is to make PASID allocation palatable for cgroup consumptions. Misc cgroup
is merged for v5.13, it can be extended for IOASID as another scalar
resource.
I have not tested on ARM platforms due to availability. Would
On Mon, May 10, 2021 at 06:25:07AM -0700, Jacob Pan wrote:
> +/*
> + * The IOMMU_SVA_BIND_SUPERVISOR flag requests a PASID which can be used only
> + * for access to kernel addresses. No IOTLB flushes are automatically done
> + * for kernel mappings; it is valid only for access to the kernel's
On 5/10/2021 11:15 AM, Julien Grall wrote:
> Hi Christoph,
>
> On 10/05/2021 09:40, Christoph Hellwig wrote:
>> On Sat, May 08, 2021 at 12:32:37AM +0100, Julien Grall wrote:
>>> The pointer dereferenced seems to suggest that the swiotlb hasn't been
>>> allocated. From what I can tell, this may
The mm parameter in iommu_sva_bind_device() is intended for privileged
process perform bind() on behalf of other processes. This use case has
yet to be materialized, let alone potential security implications of
adding kernel hooks without explicit user consent.
In addition, with the agreement that
The void* drvdata parameter isn't really used in iommu_sva_bind_device()
API, the current IDXD code "borrows" the drvdata for a VT-d private flag
for supervisor SVA usage.
Supervisor/Privileged mode request is a generic feature. It should be
promoted from the VT-d vendor driver to the generic
On Mon, 10 May 2021, Christoph Hellwig wrote:
> On Sat, May 08, 2021 at 12:32:37AM +0100, Julien Grall wrote:
> > The pointer dereferenced seems to suggest that the swiotlb hasn't been
> > allocated. From what I can tell, this may be because swiotlb_force is set
> > to SWIOTLB_NO_FORCE, we will
Hi Jason,
On Mon, 10 May 2021 20:37:49 -0300, Jason Gunthorpe wrote:
> On Mon, May 10, 2021 at 06:25:07AM -0700, Jacob Pan wrote:
>
> > +/*
> > + * The IOMMU_SVA_BIND_SUPERVISOR flag requests a PASID which can be
> > used only
> > + * for access to kernel addresses. No IOTLB flushes are
Hi Keqian,
On 5/10/21 7:07 PM, Keqian Zhu wrote:
I suppose this interface is to ask the vendor IOMMU driver to check
whether each device/iommu in the domain supports dirty bit tracking.
But what will happen if new devices with different tracking capability
are added afterward?
Yep, this is
Hi Jason,
On Mon, 10 May 2021 20:45:00 -0300, Jason Gunthorpe wrote:
> On Mon, May 10, 2021 at 03:28:54PM -0700, Jacob Pan wrote:
>
> > To satisfy your "give me a PASID for this RID" proposal, can we just use
> > the RID's struct device as the token? Also add a type field to
> > explicitly
On Mon, May 10, 2021 at 05:30:57PM +0900, Chanho Park wrote:
> +static unsigned int swiotlb_align_offset(struct device *dev, u64 addr);
Please just move swiotlb_align_offset up to avoid the forward declaration.
> /*
> * Bounce: copy the swiotlb buffer from or back to the original dma location
Hi Robin,
> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: 07 May 2021 11:02
> To: Shameerali Kolothum Thodi ;
> linux-arm-ker...@lists.infradead.org; linux-a...@vger.kernel.org;
> iommu@lists.linux-foundation.org
> Cc: Linuxarm ; lorenzo.pieral...@arm.com;
Looks good,
Reviewed-by: Christoph Hellwig
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
The iommu_device field in struct mdev_device has never been used
since it was added more than 2 years ago.
Signed-off-by: Christoph Hellwig
---
drivers/vfio/vfio_iommu_type1.c | 132 ++--
include/linux/mdev.h| 20 -
2 files changed, 25 insertions(+),
This method is never actually called. Simplify the instance in
intel-iommu that is directly called by inlining the relevant code.
Signed-off-by: Christoph Hellwig
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 1 -
drivers/iommu/intel/iommu.c | 67 ++---
These are entirely unused now, and were only called by the previously
entirely unused vfio mdev iommu interaction.
Signed-off-by: Christoph Hellwig
---
drivers/iommu/intel/iommu.c | 205
drivers/iommu/iommu.c | 33 --
include/linux/intel-iommu.h |
This feature is entirely unused, and was only ever called by unused code
either.
Signed-off-by: Christoph Hellwig
---
drivers/iommu/intel/iommu.c | 82 -
drivers/iommu/intel/svm.c | 6 ---
include/linux/intel-iommu.h | 1 -
include/linux/iommu.h |
Remove the unused iommu_dev_feature_enabled function.
Signed-off-by: Christoph Hellwig
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 1 -
drivers/iommu/iommu.c | 13 -
include/linux/iommu.h | 9 -
3 files changed, 23
This function was never used since it was added more than 2 years ago.
Signed-off-by: Christoph Hellwig
---
drivers/iommu/intel/iommu.c | 10 --
drivers/iommu/iommu.c | 11 ---
include/linux/iommu.h | 9 -
3 files changed, 30 deletions(-)
diff --git
Hi all,
this is another series to remove dead code from the IOMMU subsystem,
this time mostly about the hacky code to pass an iommu device in
struct mdev_device and huge piles of support code. All of this was
merged two years ago and (fortunately) never got used.
Note that the mdev.h changes
> -Original Message-
> From: Steven Price [mailto:steven.pr...@arm.com]
> Sent: 06 May 2021 16:17
> To: Shameerali Kolothum Thodi ;
> linux-arm-ker...@lists.infradead.org; linux-a...@vger.kernel.org;
> iommu@lists.linux-foundation.org
> Cc: Linuxarm ; lorenzo.pieral...@arm.com;
>
On Sat, May 08, 2021 at 12:32:37AM +0100, Julien Grall wrote:
> The pointer dereferenced seems to suggest that the swiotlb hasn't been
> allocated. From what I can tell, this may be because swiotlb_force is set
> to SWIOTLB_NO_FORCE, we will still enable the swiotlb when running on top
> of
On Sat, May 08, 2021 at 09:56:59AM +, Tian, Kevin wrote:
> > From: Raj, Ashok
> > Sent: Friday, May 7, 2021 12:33 AM
> >
> > > Basically it means when the guest's top level IOASID is created for
> > > nesting that IOASID claims all PASID's on the RID and excludes any
> > > PASID IOASIDs from
The restricted DMA pool is preferred if available.
The restricted DMA pools provide a basic level of protection against the
DMA overwriting buffer contents at unexpected times. However, to protect
against general data leakage and system memory corruption, the system
needs to provide a way to lock
Add the functions, swiotlb_{alloc,free} to support the memory allocation
from restricted DMA pool.
Signed-off-by: Claire Chang
---
include/linux/swiotlb.h | 4
kernel/dma/swiotlb.c| 35 +--
2 files changed, 37 insertions(+), 2 deletions(-)
diff --git
If a device is not behind an IOMMU, we look up the device node and set
up the restricted DMA when the restricted-dma-pool is presented.
Signed-off-by: Claire Chang
---
drivers/of/address.c| 25 +
drivers/of/device.c | 3 +++
drivers/of/of_private.h | 5 +
3
Introduce the new compatible string, restricted-dma-pool, for restricted
DMA. One can specify the address and length of the restricted DMA memory
region by restricted-dma-pool in the reserved-memory node.
Signed-off-by: Claire Chang
---
.../reserved-memory/reserved-memory.txt | 27
Add a new wrapper __dma_direct_free_pages() that will be useful later
for swiotlb_free().
Signed-off-by: Claire Chang
---
kernel/dma/direct.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index
Add a new function, release_slots, to make the code reusable for supporting
different bounce buffer pools, e.g. restricted DMA pool.
Signed-off-by: Claire Chang
---
kernel/dma/swiotlb.c | 35 ---
1 file changed, 20 insertions(+), 15 deletions(-)
diff --git
On Mon, May 10, 2021 at 08:53:59AM +0200, Christoph Hellwig wrote:
> Hi all,
>
> this is another series to remove dead code from the IOMMU subsystem,
> this time mostly about the hacky code to pass an iommu device in
> struct mdev_device and huge piles of support code. All of this was
> merged
From: Xiang Chen
It is not necessary to put free_iova_mem() inside of spinlock/unlock
iova_rbtree_lock which only leads to more completion for the spinlock.
It has a small promote on the performance after the change. And also
rename private_free_iova() as remove_iova() because the function will
From: Bumyong Lee
in case of driver wants to sync part of ranges with offset,
swiotlb_tbl_sync_single() copies from orig_addr base to tlb_addr with offset
it makes data mismatch
it removed from "swiotlb: don't modify orig_addr in swiotlb_tbl_sync_single",
but it have to be recovered
1. Get
(RESEND due to wrong encrypted message setting)
Hi,
> On Mon, May 10, 2021 at 05:30:57PM +0900, Chanho Park wrote:
> > +static unsigned int swiotlb_align_offset(struct device *dev, u64
> > +addr);
>
> Please just move swiotlb_align_offset up to avoid the forward declaration.
Okay. I'll move
From: Bumyong Lee
in case of driver wants to sync part of ranges with offset,
swiotlb_tbl_sync_single() copies from orig_addr base to tlb_addr with
offset it makes data mismatch
it removed from
- "swiotlb: don't modify orig_addr in swiotlb_tbl_sync_single",
but it have to be recovered due to
삼성 보안 문서
삼성 보안 문서는 PDF로 암호화 됩니다.보안문서 열람을 위해 인증 방법 및 필수 설치프로그램을 확인하여 주십시오.
1. 보안문서를 조회하려면 본인인증이 필요합니다.
- Knox Portal 사용자 : Knox Portal 아이디 + 비밀번호
- 미사용자 : E-mail주소 + *사전등록 비밀번호
*사전등록 비밀번호 : 별도 수신한 '삼성 보안 문서 열람을 위한 등록안내' 메일 참고
Add a new kconfig symbol, DMA_RESTRICTED_POOL, for restricted DMA pool.
Signed-off-by: Claire Chang
---
kernel/dma/Kconfig | 14 ++
1 file changed, 14 insertions(+)
diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
index 77b405508743..3e961dc39634 100644
--- a/kernel/dma/Kconfig
Add a new function, swiotlb_init_io_tlb_mem, for the io_tlb_mem struct
initialization to make the code reusable.
Note that we now also call set_memory_decrypted in swiotlb_init_with_tbl.
Signed-off-by: Claire Chang
---
kernel/dma/swiotlb.c | 51 ++--
1
From: Claire Chang
This series implements mitigations for lack of DMA access control on
systems without an IOMMU, which could result in the DMA accessing the
system memory at unexpected times and/or unexpected addresses, possibly
leading to data leakage or corruption.
For example, we plan to
Split the debugfs creation to make the code reusable for supporting
different bounce buffer pools, e.g. restricted DMA pool.
Signed-off-by: Claire Chang
---
kernel/dma/swiotlb.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/kernel/dma/swiotlb.c
v6: https://lore.kernel.org/patchwork/cover/1423201/
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Hi Baolu,
On 2021/5/10 9:08, Lu Baolu wrote:
> Hi Keqian,
>
> On 5/8/21 3:35 PM, Keqian Zhu wrote:
>> Hi Baolu,
>>
>> On 2021/5/8 11:46, Lu Baolu wrote:
>>> Hi Keqian,
>>>
>>> On 5/7/21 6:21 PM, Keqian Zhu wrote:
Some types of IOMMU are capable of tracking DMA dirty log, such as
ARM
Update is_swiotlb_buffer to add a struct device argument. This will be
useful later to allow for restricted DMA pool.
Signed-off-by: Claire Chang
---
drivers/iommu/dma-iommu.c | 12 ++--
drivers/xen/swiotlb-xen.c | 2 +-
include/linux/swiotlb.h | 6 +++---
kernel/dma/direct.c
Add the initialization function to create restricted DMA pools from
matching reserved-memory nodes.
Signed-off-by: Claire Chang
---
include/linux/device.h | 4 +++
include/linux/swiotlb.h | 3 +-
kernel/dma/swiotlb.c| 79 +
3 files changed, 85
Add a new getter, get_io_tlb_mem, to help select the io_tlb_mem struct.
The restricted DMA pool is preferred if available.
Signed-off-by: Claire Chang
---
include/linux/swiotlb.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
Regardless of swiotlb setting, the restricted DMA pool is preferred if
available.
The restricted DMA pools provide a basic level of protection against the
DMA overwriting buffer contents at unexpected times. However, to protect
against general data leakage and system memory corruption, the system
Move the maintenance of alloc_size to find_slots for better code
reusability later.
Signed-off-by: Claire Chang
---
kernel/dma/swiotlb.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 3f1ad080a4bc..ef04d8f7708f
Update is_swiotlb_active to add a struct device argument. This will be
useful later to allow for restricted DMA pool.
Signed-off-by: Claire Chang
---
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_ttm.c| 2 +-
drivers/pci/xen-pcifront.c
On Mon, May 10, 2021 at 10:40 AM Shameerali Kolothum Thodi
wrote:
>
>
>
> > -Original Message-
> > From: Steven Price [mailto:steven.pr...@arm.com]
> > Sent: 06 May 2021 16:17
> > To: Shameerali Kolothum Thodi ;
> > linux-arm-ker...@lists.infradead.org; linux-a...@vger.kernel.org;
> >
> +static inline struct io_tlb_mem *get_io_tlb_mem(struct device *dev)
> +{
> +#ifdef CONFIG_DMA_RESTRICTED_POOL
> + if (dev && dev->dma_io_tlb_mem)
> + return dev->dma_io_tlb_mem;
> +#endif /* CONFIG_DMA_RESTRICTED_POOL */
> +
> + return io_tlb_default_mem;
Given that we're
On Mon, May 10, 2021 at 09:37:29AM -0300, Jason Gunthorpe wrote:
> On Sat, May 08, 2021 at 09:56:59AM +, Tian, Kevin wrote:
> > > From: Raj, Ashok
> > > Sent: Friday, May 7, 2021 12:33 AM
> > >
> > > > Basically it means when the guest's top level IOASID is created for
> > > > nesting that
Hi all,
swiotlb_max_segment is a rather strange "API" export by swiotlb.c,
and i915 is the only (remaining) user.
swiotlb_max_segment returns 0 if swiotlb is not in use, 1 if
SWIOTLB_FORCE is set or swiotlb-zen is set, and the swiotlb segment
size when swiotlb is otherwise enabled.
i915 then
On Mon, May 10, 2021 at 08:25:02AM -0700, Raj, Ashok wrote:
> Global PASID doesn't break anything, but giving that control to vIOMMU
> doesn't seem right. When we have mixed uses cases like hardware that
> supports shared wq and SRIOV devices that need PASIDs we need to
> comprehend how they
> +#ifdef CONFIG_DMA_RESTRICTED_POOL
> +#include
> +#include
> +#include
> +#include
> +#include
> +#endif
I don't think any of this belongs into swiotlb.c. Marking
swiotlb_init_io_tlb_mem non-static and having all this code in a separate
file is probably a better idea.
> +#ifdef
On 2021-05-10 10:19, Shameerali Kolothum Thodi wrote:
Hi Robin,
-Original Message-
From: Robin Murphy [mailto:robin.mur...@arm.com]
Sent: 07 May 2021 11:02
To: Shameerali Kolothum Thodi ;
linux-arm-ker...@lists.infradead.org; linux-a...@vger.kernel.org;
iommu@lists.linux-foundation.org
For streaming DMA mappings involving an IOMMU and whose IOVA len regularly
exceeds the IOVA rcache upper limit (meaning that they are not cached),
performance can be reduced.
This is much more pronounced from commit 4e89dce72521 ("iommu/iova: Retry
from last rb tree node if iova search fails"),
Add a function to re-alloc IOMMU group default domain.
Signed-off-by: John Garry
---
drivers/iommu/iommu.c | 12
include/linux/iommu.h | 6 ++
2 files changed, 18 insertions(+)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index f7253a973ab9..bdb9aa47dfca 100644
Add a function to return the max optimised DMA size for an IOMMU group.
Signed-off-by: John Garry
---
drivers/iommu/iommu.c | 5 +
include/linux/iommu.h | 6 ++
2 files changed, 11 insertions(+)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 63cdfb11ebed..62e4491f32e0
Add support to allow the maximum optimised DMA len be set for an IOMMU
group via sysfs.
This much the same with the method to change the default domain type for a
group.
However, unlike changing the default domain type, the new domains will be
allocated on a member device reprobe path.
Function iommu_group_store_type() supports changing the default domain of
an IOMMU group.
Many conditions need to be satisfied and steps taken for this action to be
successful.
Satisfying these conditions and steps will be required for setting other
IOMMU group attributes, so factor into a
Add a function to reconfigure the IOMMU group for a device, if necessary.
IOVAs are cached in power-of-2 granules, so there is no point in allocating
a new IOMMU domain if the current range is suitable.
Signed-off-by: John Garry
---
drivers/iommu/dma-iommu.c | 25 +
Add extended version of init_iova_domain() which accepts an max opt
iova length argument, and use it to set the rcaches range.
Signed-off-by: John Garry
---
drivers/iommu/iova.c | 29 +++--
include/linux/iova.h | 9 +
2 files changed, 32 insertions(+), 6
Some LLDs may request DMA mappings whose IOVA length exceeds that of the
current rcache upper limit.
This means that allocations for those IOVAs will never be cached, and
always must be allocated and freed from the RB tree per DMA mapping cycle.
This has a significant effect on performance, more
Add a function which allows the max optimised IOMMU DMA size to be set.
When set successfully, return -EPROBE_DEFER to inform the caller that the
device driver needs to be reprobed to take effect.
Signed-off-by: John Garry
---
drivers/iommu/iommu.c | 47
Add iommu_dma_set_opt_size(), which is a frontend for
iommu_set_dev_dma_opt_size().
Signed-off-by: John Garry
---
drivers/iommu/dma-iommu.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 1d58c7a2d85d..fd62afe7c7d0 100644
---
Call iommu_reconfig_dev_group_dma() from iommu_setup_dma_ops() to reconfig
the group domain, if necessary.
Signed-off-by: John Garry
---
drivers/iommu/dma-iommu.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index
Add a function to allow the max size which we want to optimise DMA mappings
for.
Signed-off-by: John Garry
---
include/linux/dma-map-ops.h | 1 +
include/linux/dma-mapping.h | 8
kernel/dma/mapping.c| 11 +++
3 files changed, 20 insertions(+)
diff --git
Allow iommu_change_dev_def_domain() to create a new default domain, keeping
the same as current in case type argument is not set.
Also remove comment about function purpose, which will become stale.
Signed-off-by: John Garry
---
drivers/iommu/iommu.c | 53
Pass the max opt iova len to init the IOVA domain, if set.
Signed-off-by: John Garry
---
drivers/iommu/dma-iommu.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 4fb82c554ede..574d7a901fd2 100644
Add a function to check whether an IOVA domain currently caches a given
upper IOVA len exactly.
Signed-off-by: John Garry
---
drivers/iommu/iova.c | 11 +++
include/linux/iova.h | 8 +++-
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/iova.c
For IOMMU strict mode, gives a big performance boost in some scenarios.
Signed-off-by: John Garry
---
drivers/scsi/hisi_sas/hisi_sas_v3_hw.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
index
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
> +static inline bool is_dev_swiotlb_force(struct device *dev)
> +{
> +#ifdef CONFIG_DMA_RESTRICTED_POOL
> + if (dev->dma_io_tlb_mem)
> + return true;
> +#endif /* CONFIG_DMA_RESTRICTED_POOL */
> + return false;
> +}
> +
> /* If SWIOTLB is active, use its maximum mapping
drivers/iommu/iova.c:50:1: warning: symbol '__init_iova_domain' was not
declared. Should it be static?
Reported-by: kernel test robot
Signed-off-by: kernel test robot
---
iova.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
Hi John,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.13-rc1 next-20210510]
[cannot apply to iommu/next mkp-scsi/for-next scsi/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when
On Mon, May 10, 2021 at 08:54:02AM +0200, Christoph Hellwig wrote:
> The iommu_device field in struct mdev_device has never been used
> since it was added more than 2 years ago.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/vfio/vfio_iommu_type1.c | 132 ++--
>
On Mon, May 10, 2021 at 12:31:11PM -0300, Jason Gunthorpe wrote:
> On Mon, May 10, 2021 at 08:25:02AM -0700, Raj, Ashok wrote:
>
> > Global PASID doesn't break anything, but giving that control to vIOMMU
> > doesn't seem right. When we have mixed uses cases like hardware that
> > supports shared
On Mon, May 10, 2021 at 09:22:12AM -0700, Raj, Ashok wrote:
> Those vIOMMU's will have a capability that it supports PASID allocation
> interface. When you allocate you can say what type of PASID you need
> (shared vs local) and Qemu will obtain either within the local range, or in
> the shared
Hi Christoph,
On 10/05/2021 09:40, Christoph Hellwig wrote:
On Sat, May 08, 2021 at 12:32:37AM +0100, Julien Grall wrote:
The pointer dereferenced seems to suggest that the swiotlb hasn't been
allocated. From what I can tell, this may be because swiotlb_force is set
to SWIOTLB_NO_FORCE, we
80 matches
Mail list logo
