On Fri, 2022-01-28 at 23:24 +0100, Daniel Vetter wrote:
> On Fri, Jan 28, 2022 at 04:11:01PM +0800, Yong Wu wrote:
> > The component requires the compare/release functions, there are so
> > many
> > copy in current kernel. Just define three common helpers for them.
> > No functional change.
> >
>
On Fri, 2022-01-28 at 13:04 +, Robin Murphy wrote:
> On 2022-01-28 08:11, Yong Wu wrote:
> [...]
> > diff --git a/include/linux/component.h b/include/linux/component.h
> > index 16de18f473d7..5a7468ea827c 100644
> > --- a/include/linux/component.h
> > +++ b/include/linux/component.h
> > @@
Thanks,
applied to the dma-mapping tree for 5.18.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Hi Fenghua,
On Mon, 7 Feb 2022 15:02:48 -0800, Fenghua Yu wrote:
> @@ -1047,8 +1040,6 @@ struct iommu_sva *intel_svm_bind(struct device
> *dev, struct mm_struct *mm, void }
>
> sva = intel_svm_bind_mm(iommu, dev, mm, flags);
> - if (IS_ERR_OR_NULL(sva))
> -
Hi Andy,
On 2/10/22 1:49 AM, Andy Shevchenko wrote:
While in this particular case it would not be a (critical) issue,
the pattern itself is bad and error prone in case the location
of the parameter is changed.
Don't cast parameter to unsigned long pointer in for_each_set_bit().
Instead copy to
On 2/9/22 9:41 PM, Jason Gunthorpe wrote:
On Tue, Feb 08, 2022 at 09:25:58AM +0800, Lu Baolu wrote:
Convert all the feasible instances of dev->bus->iommu_ops to
dev_iommu_ops() in order to making the operation of obtaining
iommu_ops from a device consistent.
Why are there two patches doing
Hello Suravee,
On Wed, Feb 09, 2022 at 12:04:40AM +0700, Suthikulpanit, Suravee wrote:
> Could you please try the following change to see if this fix the problem?
>
> diff --git a/drivers/iommu/amd/io_pgtable.c b/drivers/iommu/amd/io_pgtable.c
> index 182c93a43efd..1eddf557636d 100644
> ---
On 2/9/22 9:52 PM, Robin Murphy wrote:
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index 2b5f4e57a8bb..80f1294be634 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -5052,8 +5052,7 @@ intel_iommu_dev_disable_feat(struct device *dev,
enum
On 2/9/22 9:31 PM, Jason Gunthorpe wrote:
On Tue, Feb 08, 2022 at 09:25:55AM +0800, Lu Baolu wrote:
The supported page sizes of an iommu_domain are saved in the pgsize_bitmap
field. Retrieve the value from the right place.
Signed-off-by: Lu Baolu
Reviewed-by: Robin Murphy
Hi Jason,
On 2/9/22 9:29 PM, Jason Gunthorpe wrote:
diff --git a/include/uapi/linux/iommu.h b/include/uapi/linux/iommu.h
index 59178fc229ca..65d8b0234f69 100644
--- a/include/uapi/linux/iommu.h
+++ b/include/uapi/linux/iommu.h
@@ -158,185 +158,4 @@ struct iommu_page_response {
__u32
Hi Joerg,
On Thu, 3 Feb 2022 09:25:58 +0100, Joerg Roedel wrote:
> On Tue, Feb 01, 2022 at 11:19:18AM -0800, Jacob Pan wrote:
> > Do you mean having an IRQ remapping notifier regardless IOMMU-API is
> > enabled, right?
> > It make sense, I will give it a try.
>
> Yeah, that would be best. I
On Tue, 08 Feb 2022 09:20:29 +0900, Yoshihiro Shimoda wrote:
> Document the compatible values for the IPMMU-VMSA blocks in
> the Renesas R-Car S4-8 (R8A779F0) SoC and R-Car Gen4.
>
> Signed-off-by: Yoshihiro Shimoda
> Reviewed-by: Geert Uytterhoeven
> ---
>
From: Vijayanand Jitta
[ Upstream commit b54240ad494300ff0994c4539a531727874381f4 ]
Kasan has reported the following use after free on dev->iommu.
when a device probe fails and it is in process of freeing dev->iommu
in dev_iommu_free function, a deferred_probe_work_func runs in parallel
and
From: Vijayanand Jitta
[ Upstream commit b54240ad494300ff0994c4539a531727874381f4 ]
Kasan has reported the following use after free on dev->iommu.
when a device probe fails and it is in process of freeing dev->iommu
in dev_iommu_free function, a deferred_probe_work_func runs in parallel
and
From: Vijayanand Jitta
[ Upstream commit b54240ad494300ff0994c4539a531727874381f4 ]
Kasan has reported the following use after free on dev->iommu.
when a device probe fails and it is in process of freeing dev->iommu
in dev_iommu_free function, a deferred_probe_work_func runs in parallel
and
While in this particular case it would not be a (critical) issue,
the pattern itself is bad and error prone in case the location
of the parameter is changed.
Don't cast parameter to unsigned long pointer in for_each_set_bit().
Instead copy to a local variable on stack of a proper type and use.
On Sun, Feb 06, 2022 at 11:27:00PM +0100, Janne Grunau wrote:
> On 2021-09-15 17:19:39 +0200, Thierry Reding wrote:
> > On Tue, Sep 07, 2021 at 07:44:44PM +0200, Thierry Reding wrote:
> > > On Tue, Sep 07, 2021 at 10:33:24AM -0500, Rob Herring wrote:
> > > > On Fri, Sep 3, 2021 at 10:36 AM Thierry
iommu_dma_get_resv_regions() assumes that iommu_fwspec field for
corresponding device is set which is not always true. Since
iommu_dma_get_resv_regions() seems to be a future-proof generic API
that can be used by any iommu driver, add an explicit check for NULL.
Currently it can work by accident
在 2022/2/9 15:40, Christoph Hellwig 写道:
On Tue, Feb 08, 2022 at 03:19:20PM +0800, Guixin Liu wrote:
This patch includes a modification to repace mutex info_lock with
percpu_ref, in order to improve uio performance.
What performance critical use case do you have for uio? Everyone really
On 2022-02-08 01:25, Lu Baolu wrote:
The is_attach_deferred iommu_ops callback is a device op. The domain
argument is unnecessary and never used. Remove it to make code clean.
Suggested-by: Robin Murphy
Signed-off-by: Lu Baolu
---
include/linux/iommu.h | 2 +-
On Tue, Feb 08, 2022 at 10:46:14PM -0800, Christoph Hellwig wrote:
> On Tue, Feb 08, 2022 at 09:25:59AM +0800, Lu Baolu wrote:
> > Move the domain specific operations out of struct iommu_ops into a new
> > structure that only has domain specific operations. This solves the
> > problem of needing
On Tue, Feb 08, 2022 at 09:25:58AM +0800, Lu Baolu wrote:
> Convert all the feasible instances of dev->bus->iommu_ops to
> dev_iommu_ops() in order to making the operation of obtaining
> iommu_ops from a device consistent.
Why are there two patches doing this conversion? Roll this into the
prior
On Tue, Feb 08, 2022 at 09:25:57AM +0800, Lu Baolu wrote:
> The is_attach_deferred iommu_ops callback is a device op. The domain
> argument is unnecessary and never used. Remove it to make code clean.
>
> Suggested-by: Robin Murphy
> Signed-off-by: Lu Baolu
> ---
> include/linux/iommu.h
On Tue, Feb 08, 2022 at 09:25:56AM +0800, Lu Baolu wrote:
> The common iommu_ops is hooked to both device and domain. When a helper
> has both device and domain pointer, the way to get the iommu_ops looks
> messy in iommu core. This sorts out the way to get iommu_ops. The device
> related helpers
On Tue, Feb 08, 2022 at 09:25:55AM +0800, Lu Baolu wrote:
> The supported page sizes of an iommu_domain are saved in the pgsize_bitmap
> field. Retrieve the value from the right place.
>
> Signed-off-by: Lu Baolu
> Reviewed-by: Robin Murphy
> Link:
>
On Tue, Feb 08, 2022 at 09:25:54AM +0800, Lu Baolu wrote:
> The apply_resv_region callback in iommu_ops was introduced to reserve an
> IOVA range in the given DMA domain when the IOMMU driver manages the IOVA
> by itself. As all drivers converted to use dma-iommu in the core, there's
> no driver
On Tue, Feb 08, 2022 at 09:25:53AM +0800, Lu Baolu wrote:
> The aux-domain related interfaces and iommu_ops are not referenced
> anywhere in the tree. We've also reached a consensus to redesign it
> based the new iommufd framework. Remove them to avoid dead code.
>
> Signed-off-by: Lu Baolu
>
On Tue, Feb 08, 2022 at 09:25:52AM +0800, Lu Baolu wrote:
> The aux-domain related callbacks are not called in the tree. Remove them
> to avoid dead code.
>
> Signed-off-by: Lu Baolu
> Reviewed-by: Christoph Hellwig
> ---
> include/linux/intel-iommu.h | 17 --
>
On Tue, Feb 08, 2022 at 09:25:51AM +0800, Lu Baolu wrote:
> The guest pasid related uapi interfaces and definitions are not referenced
> anywhere in the tree. We've also reached a consensus to replace them with
> a new iommufd design. Remove them to avoid dead code.
>
> Signed-off-by: Lu Baolu
>
On Tue, Feb 08, 2022 at 09:25:50AM +0800, Lu Baolu wrote:
> The guest pasid related callbacks are not called in the tree. Remove them
> to avoid dead code.
>
> Signed-off-by: Lu Baolu
> Reviewed-by: Christoph Hellwig
> ---
> include/linux/intel-iommu.h | 10 --
> include/linux/intel-svm.h |
On 2022-02-09 02:50, Martin Oliveira wrote:
Hello,
We have been hitting an error when running IO over our nvme-of setup, using the
mlx5 driver and we are wondering if anyone has seen anything similar/has any
suggestions.
Both initiator and target are AMD EPYC 7502 machines connected over
From: Tianyu Lan
In Hyper-V Isolation VM, swiotlb bnounce buffer size maybe 1G at most
and there maybe no enough memory from 0 to 4G according to memory layout.
Devices in Isolation VM can use memory above 4G as DMA memory and call
swiotlb_alloc_from_low_pages() to allocate swiotlb bounce buffer
From: Tianyu Lan
Hyper-V Isolation VM and AMD SEV VM uses swiotlb bounce buffer to
share memory with hypervisor. Current swiotlb bounce buffer is only
allocated from 0 to ARCH_LOW_ADDRESS_LIMIT which is default to
0xUL. Isolation VM and AMD SEV VM needs 1G bounce buffer at most.
This
From: Tianyu Lan
Hyper-V Isolation VM may fail to allocate swiotlb bounce buffer due
to there is no enough contiguous memory from 0 to 4G in some cases.
Current swiotlb code allocates bounce buffer in the low end memory.
This patchset adds a new function swiotlb_set_alloc_from_low_pages()
to
On Mon, Feb 07, 2022 at 04:12:40PM +0200, Andy Shevchenko wrote:
> Compiler is not happy about hidden declaration of intel_iommu_ops.
>
> .../iommu.c:414:24: warning: symbol 'intel_iommu_ops' was not declared.
> Should it be static?
>
> Move declaration to header file to make compiler happy.
On Tue, Feb 08, 2022 at 11:06:56PM -0800, Christoph Hellwig wrote:
> On Mon, Feb 07, 2022 at 03:55:32PM +, Robin Murphy wrote:
> > On 2022-02-07 14:13, Andy Shevchenko wrote:
> > > Use DMA ops setter instead of direct assignment. Even we know that
> > > this module doesn't perform access to
On 2/8/22 6:50 PM, Martin Oliveira wrote:
> Hello,
>
> We have been hitting an error when running IO over our nvme-of setup, using
> the mlx5 driver and we are wondering if anyone has seen anything similar/has
> any suggestions.
>
> Both initiator and target are AMD EPYC 7502 machines
37 matches
Mail list logo
