On Tue Dec 10 19, Lu Baolu wrote:
Hi,
On 12/10/19 2:16 PM, Jerry Snitselaar wrote:
On Mon Dec 09 19, Jerry Snitselaar wrote:
On Mon Dec 09 19, Jerry Snitselaar wrote:
On Mon Dec 09 19, Jerry Snitselaar wrote:
[snip]
A call to iommu_map is failing.
[ 36.686881] pci :01:00.2:
Hi,
On 12/10/19 2:16 PM, Jerry Snitselaar wrote:
On Mon Dec 09 19, Jerry Snitselaar wrote:
On Mon Dec 09 19, Jerry Snitselaar wrote:
On Mon Dec 09 19, Jerry Snitselaar wrote:
[snip]
A call to iommu_map is failing.
[ 36.686881] pci :01:00.2: iommu_group_add_device: calling
On Mon Dec 09 19, Jerry Snitselaar wrote:
On Mon Dec 09 19, Jerry Snitselaar wrote:
On Mon Dec 09 19, Jerry Snitselaar wrote:
[snip]
A call to iommu_map is failing.
[ 36.686881] pci :01:00.2: iommu_group_add_device: calling
iommu_group_create_direct_mappings
[ 36.689843] pci
On 2019/12/10 上午2:05, Jean-Philippe Brucker wrote:
Add support for Substream ID and PASIDs to the SMMUv3 driver.
Changes since v2 [1]:
* Split preparatory work into patches 5, 6, 8 and 9.
* Added patch 1. Not strictly relevant, but since we're moving the DMA
allocations and adding a new
On Mon Dec 09 19, Jerry Snitselaar wrote:
On Mon Dec 09 19, Jerry Snitselaar wrote:
[snip]
A call to iommu_map is failing.
[ 36.686881] pci :01:00.2: iommu_group_add_device: calling
iommu_group_create_direct_mappings
[ 36.689843] pci :01:00.2: iommu_group_create_direct_mappings:
Hi,
On 12/10/19 1:18 PM, Jerry Snitselaar wrote:
On Mon Dec 09 19, Jerry Snitselaar wrote:
[snip]
A call to iommu_map is failing.
[ 36.686881] pci :01:00.2: iommu_group_add_device: calling
iommu_group_create_direct_mappings
[ 36.689843] pci :01:00.2:
On Mon Dec 09 19, Jerry Snitselaar wrote:
[snip]
A call to iommu_map is failing.
[ 36.686881] pci :01:00.2: iommu_group_add_device: calling
iommu_group_create_direct_mappings
[ 36.689843] pci :01:00.2: iommu_group_create_direct_mappings: iterating
through mappings
[ 36.692757]
Hi,
On 12/10/19 11:47 AM, Jerry Snitselaar wrote:
So the domain type is dma after 01:00.0 gets added, and when
intel_iommu_add_device is called for 01:00.2 it will go into the if
section. Since the device default domain type for 01:00.2 is dma
nothing happens in there, and it goes on to
During ethernet(Marvell octeontx2) set ring buffer test:
ethtool -G eth1 rx tx
following kmemleak will happen sometimes:
unreferenced object 0x000b85421340 (size 64):
comm "ethtool", pid 867, jiffies 4295323539 (age 550.500s)
hex dump (first 64 bytes):
80 13 42 85 0b 00 ff ff ff ff
> -Original Message-
> From: Robin Murphy
> Sent: Tuesday, December 10, 2019 3:34 AM
> To: Yin, Xiaotao ; j...@8bytes.org;
> iommu@lists.linux-foundation.org
> Cc: linux-ker...@vger.kernel.org; Hao, Kexin
> Subject: Re: [PATCH V2] iommu/iova: Init the struct iova to fix the possible
>
On Tue Dec 10 19, Lu Baolu wrote:
Hi,
On 12/10/19 8:52 AM, Jerry Snitselaar wrote:
On Sun Dec 08 19, Lu Baolu wrote:
Hi,
On 12/7/19 10:41 AM, Jerry Snitselaar wrote:
On Fri Dec 06 19, Jerry Snitselaar wrote:
On Sat Dec 07 19, Lu Baolu wrote:
Hi Jerry,
On 12/6/19 3:24 PM, Jerry Snitselaar
From: Kenneth Lee
Uacce (Unified/User-space-access-intended Accelerator Framework) targets to
provide Shared Virtual Addressing (SVA) between accelerators and processes.
So accelerator can access any data structure of the main cpu.
This differs from the data sharing between cpu and io device,
Remove the module_param uacce_mode, which is not used currently.
Signed-off-by: Zhangfei Gao
Signed-off-by: Zhou Wang
---
drivers/crypto/hisilicon/zip/zip_main.c | 31 ++-
1 file changed, 6 insertions(+), 25 deletions(-)
diff --git
Uacce (Unified/User-space-access-intended Accelerator Framework) targets to
provide Shared Virtual Addressing (SVA) between accelerators and processes.
So accelerator can access any data structure of the main cpu.
This differs from the data sharing between cpu and io device, which share
data
From: Kenneth Lee
Uacce (Unified/User-space-access-intended Accelerator Framework) is
a kernel module targets to provide Shared Virtual Addressing (SVA)
between the accelerator and process.
This patch add document to explain how it works.
Signed-off-by: Kenneth Lee
Signed-off-by: Zaibo Xu
Hi,
On 12/10/19 8:52 AM, Jerry Snitselaar wrote:
On Sun Dec 08 19, Lu Baolu wrote:
Hi,
On 12/7/19 10:41 AM, Jerry Snitselaar wrote:
On Fri Dec 06 19, Jerry Snitselaar wrote:
On Sat Dec 07 19, Lu Baolu wrote:
Hi Jerry,
On 12/6/19 3:24 PM, Jerry Snitselaar wrote:
On Fri Dec 06 19, Lu Baolu
Hi Jacob,
This has been queued for internal test. I will forward it to Joerg if
everything goes well (probably around rc4).
Best regards,
-baolu
On 12/10/19 1:14 AM, Jacob Pan wrote:
Hi Joerg and Baolu,
Any more comments on this series? I rebased it on v5.5-rc1 without
changes.
Thanks,
On Sun Dec 08 19, Lu Baolu wrote:
Hi,
On 12/7/19 10:41 AM, Jerry Snitselaar wrote:
On Fri Dec 06 19, Jerry Snitselaar wrote:
On Sat Dec 07 19, Lu Baolu wrote:
Hi Jerry,
On 12/6/19 3:24 PM, Jerry Snitselaar wrote:
On Fri Dec 06 19, Lu Baolu wrote:
[snip]
Can you please try below change?
From: Ashish Kalra
For SEV, all DMA to and from guest has to use shared
(un-encrypted) pages. SEV uses SWIOTLB to make this happen
without requiring changes to device drivers. However,
depending on workload being run, the default 64MB of SWIOTLB
might not be enough and SWIOTLB may run out of
On Fri, Nov 22, 2019 at 3:32 PM Jordan Crouse wrote:
>
> Attempt to enable split pagetables if the arm-smmu driver supports it.
> This will move the default address space from the default region to
> the address range assigned to TTBR1. The behavior should be transparent
> to the driver for now
On Fri, Nov 22, 2019 at 3:32 PM Jordan Crouse wrote:
>
> Refactor how address space initialization works. Instead of having the
> address space function create the MMU object (and thus require separate but
> equal functions for gpummu and iommu) use a single function and pass the
> MMU struct in.
On Fri, Nov 22, 2019 at 3:32 PM Jordan Crouse wrote:
>
> Everywhere an IOMMU object is created by msm_gpu_create_address_space
> the IOMMU device is attached immediately after. Instead of carrying around
> the infrastructure to do the attach from the device specific code do it
> directly in the
Since commit ece6e6f0218b ("iommu/dma-iommu: Split iommu_dma_map_msi_msg()
in two parts"), iommu_dma_prepare_msi() should no longer have to worry
about preempting itself, nor being called in atomic context at all. Thus
we can downgrade the IRQ-safe locking to a simple mutex to avoid angering
the
On 09/12/2019 8:24 am, Xiaotao Yin wrote:
During ethernet(Marvell octeontx2) set ring buffer test:
ethtool -G eth1 rx tx
following kmemleak will happen sometimes:
unreferenced object 0x000b85421340 (size 64):
comm "ethtool", pid 867, jiffies 4295323539 (age 550.500s)
hex dump (first
Enable PASID for PCI devices that support it. Since the SSID tables are
allocated by arm_smmu_attach_dev(), PASID has to be enabled early enough.
arm_smmu_dev_feature_enable() would be too late, since by that time the
main DMA domain has already been attached. Do it in add_device() instead.
Now that we support substream IDs, initialize s1cdmax with the number of
SSID bits supported by a master and the SMMU.
Context descriptor tables are allocated once for the first master
attached to a domain. Therefore attaching multiple devices with
different SSID sizes is tricky, and we currently
The SMMU can support up to 20 bits of SSID. Add a second level of page
tables to accommodate this. Devices that support more than 1024 SSIDs now
have a table of 1024 L1 entries (8kB), pointing to tables of 1024 context
descriptors (64kB), allocated on demand.
Signed-off-by: Jean-Philippe Brucker
Add support for Substream ID and PASIDs to the SMMUv3 driver.
Changes since v2 [1]:
* Split preparatory work into patches 5, 6, 8 and 9.
* Added patch 1. Not strictly relevant, but since we're moving the DMA
allocations and adding a new one, we might as well clean the flags
first.
* Fixed a
Support for SSID will require allocating context descriptor tables. Move
the context descriptor allocation to separate functions.
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/arm-smmu-v3.c | 57 ++---
1 file changed, 46 insertions(+), 11 deletions(-)
Since commit 518a2f1925c3 ("dma-mapping: zero memory returned from
dma_alloc_*"), dma_alloc_* always initializes memory to zero, so there
is no need to use dma_zalloc_* or pass the __GFP_ZERO flag anymore.
The flag was introduced by commit 04fa26c71be5 ("iommu/arm-smmu: Convert
DMA buffer
The SMMUv3 driver, which may be built without CONFIG_PCI, will soon gain
PASID support. Partially revert commit c6e9aefbf9db ("PCI/ATS: Remove
unused PRI and PASID stubs") to re-introduce the PASID stubs, and avoid
adding more #ifdefs to the SMMU driver.
Signed-off-by: Jean-Philippe Brucker
---
On Arm systems, some platform devices behind an SMMU may support the PASID
feature, which offers multiple address space. Let the firmware tell us
when a device supports PASID.
Reviewed-by: Rob Herring
Reviewed-by: Eric Auger
Signed-off-by: Jean-Philippe Brucker
---
At the moment, the SMMUv3 driver implements only one stage-1 or stage-2
page directory per device. However SMMUv3 allows more than one address
space for some devices, by providing multiple stage-1 page directories. In
addition to the Stream ID (SID), that identifies a device, we can now have
When adding SSID support to the SMMUv3 driver, we'll need to manipulate
leaf pasid tables and context descriptors. Extract the context
descriptor structure and introduce a new table structure.
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/arm-smmu-v3.c | 44
Second-level context descriptor tables will be allocated lazily in
arm_smmu_write_ctx_desc(). Help with handling allocation failure by
moving the CD write into arm_smmu_domain_finalise_s1().
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/arm-smmu-v3.c | 11 +++
1 file changed, 7
Named component nodes in the IORT tables describe the number of
Substream ID bits (aka. PASID) supported by the device. Propagate this
value to the fwspec structure in order to enable PASID for platform
devices.
Acked-by: Hanjun Guo
Signed-off-by: Jean-Philippe Brucker
---
Let add_device() clean up after itself. The iommu_bus_init() function
does call remove_device() on error, but other sites (e.g. of_iommu) do
not.
Don't free level-2 stream tables because we'd have to track if we
allocated each of them or if they are used by other endpoints. It's not
worth the
For platform devices that support SubstreamID (SSID), firmware provides
the number of supported SSID bits. Restrict it to what the SMMU supports
and cache it into master->ssid_bits, which will also be used for PCI
PASID.
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/arm-smmu-v3.c | 13
Hi Joerg and Baolu,
Any more comments on this series? I rebased it on v5.5-rc1 without
changes.
Thanks,
Jacob
On Mon, 2 Dec 2019 11:58:21 -0800
Jacob Pan wrote:
> Mostly extracted from nested SVA/SVM series based on review comments
> of v7. https://lkml.org/lkml/2019/10/24/852
>
> This
From: Thierry Reding
This function will be subsequently used to extract stream ID information
early, before a struct device is available.
Signed-off-by: Thierry Reding
---
drivers/iommu/arm-smmu.c | 24 +---
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git
From: Thierry Reding
On platforms, the firmware will setup hardware to read from a given
region of memory. One such example is a display controller that is
scanning out a splash screen from physical memory.
During Linux's boot process, the ARM SMMU will configure all contexts to
fault by
From: Thierry Reding
On some platforms, the firmware will setup hardware to read from a given
region of memory. One such example is a display controller that is
scanning out a splash screen from physical memory.
During Linux' boot process, the ARM SMMU will configure all contexts to
fault by
From: Thierry Reding
Most IOMMU drivers only need to free the memory allocated for each
reserved region. Instead of open-coding the loop to do this in each
driver, extract the code into a common function that can be used by
all these drivers.
Changes in v2:
- change subject prefix to "iommu:
From: Thierry Reding
Implement a generic function for removing reserved regions. This can be
used by drivers that don't do anything fancy with these regions other
than allocating memory for them.
Signed-off-by: Thierry Reding
---
drivers/iommu/iommu.c | 19 +++
From: Thierry Reding
Use the new standard function instead of open-coding it.
Cc: Jean-Philippe Brucker
Cc: virtualizat...@lists.linux-foundation.org
Signed-off-by: Thierry Reding
---
Changes in v2:
- change subject prefix to 'iommu: virt:' to 'iommu: virtio:'
drivers/iommu/virtio-iommu.c |
From: Thierry Reding
Use the new standard function instead of open-coding it.
Cc: Will Deacon
Cc: Robin Murphy
Signed-off-by: Thierry Reding
---
drivers/iommu/arm-smmu-v3.c | 11 +--
drivers/iommu/arm-smmu.c| 11 +--
2 files changed, 2 insertions(+), 20 deletions(-)
From: Thierry Reding
Use the new standard function instead of open-coding it.
Signed-off-by: Thierry Reding
---
drivers/iommu/amd_iommu.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index
From: Thierry Reding
Use the new standard function instead of open-coding it.
Cc: David Woodhouse
Signed-off-by: Thierry Reding
---
drivers/iommu/intel-iommu.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c
From: Thierry Reding
For device tree nodes, use the standard of_iommu_get_resv_regions()
implementation to obtain the reserved memory regions associated with a
device.
Cc: Rob Herring
Cc: Frank Rowand
Cc: devicet...@vger.kernel.org
Signed-off-by: Thierry Reding
---
drivers/iommu/dma-iommu.c
From: Thierry Reding
This is an implementation that IOMMU drivers can use to obtain reserved
memory regions from a device tree node. It uses the reserved-memory DT
bindings to find the regions associated with a given device. These
regions will be used to create 1:1 mappings in the IOMMU domain
On Mon, Dec 09, 2019 at 12:55:22PM +, Robin Murphy wrote:
> On 09/12/2019 12:38 pm, Jean-Philippe Brucker wrote:
> > Since commit 781ca2de89ba ("iommu: Add gfp parameter to
> > iommu_ops::map"), iommu_map() might sleep. iommu_dma_get_msi_page() runs
> > in atomic context and thus should call
It makes little sense for dma_limit to be a dma_addr_t when we only use
it to pass u64 arguments, and combine it with another u64 along the way.
Just make it u64, and head off any possible size mismatches.
Signed-off-by: Robin Murphy
---
drivers/iommu/dma-iommu.c | 2 +-
1 file changed, 1
On 09/12/2019 12:38 pm, Jean-Philippe Brucker wrote:
Since commit 781ca2de89ba ("iommu: Add gfp parameter to
iommu_ops::map"), iommu_map() might sleep. iommu_dma_get_msi_page() runs
in atomic context and thus should call iommu_map_atomic() instead.
Spooky... I'm rebasing my local branches and
Since commit 781ca2de89ba ("iommu: Add gfp parameter to
iommu_ops::map"), iommu_map() might sleep. iommu_dma_get_msi_page() runs
in atomic context and thus should call iommu_map_atomic() instead.
Fixes: 781ca2de89ba ("iommu: Add gfp parameter to iommu_ops::map")
Signed-off-by: Jean-Philippe
During ethernet(Marvell octeontx2) set ring buffer test:
ethtool -G eth1 rx tx
following kmemleak will happen sometimes:
unreferenced object 0x000b85421340 (size 64):
comm "ethtool", pid 867, jiffies 4295323539 (age 550.500s)
hex dump (first 64 bytes):
80 13 42 85 0b 00 ff ff ff ff
Changed the title to "Init the struct iova to fix the possible memleak".
Thanks~
Br.
-Original Message-
From: Xiaotao Yin
Sent: Monday, December 9, 2019 3:16 PM
To: j...@8bytes.org; iommu@lists.linux-foundation.org
Cc: linux-ker...@vger.kernel.org; Hao, Kexin ; Yin,
Xiaotao
Subject:
Please ignore this one, I'll send v2.
Br.
-Original Message-
From: Yin, Xiaotao
Sent: Monday, December 9, 2019 3:24 PM
To: Yin, Xiaotao ; j...@8bytes.org;
iommu@lists.linux-foundation.org
Cc: linux-ker...@vger.kernel.org; Hao, Kexin
Subject: RE: [PATCH] iommu/iova: Init the struct
Please ignore this one, I'll send v2.
Br.
-Original Message-
From: Xiaotao Yin
Sent: Monday, December 9, 2019 3:16 PM
To: j...@8bytes.org; iommu@lists.linux-foundation.org
Cc: linux-ker...@vger.kernel.org; Hao, Kexin ; Yin,
Xiaotao
Subject: [PATCH] iommu/iova: kmemleak when pfn_lo
During ethernet(Marvell octeontx2) set ring buffer test:
ethtool -G eth1 rx tx
following kmemleak will happen sometimes:
unreferenced object 0x000b85421340 (size 64):
comm "ethtool", pid 867, jiffies 4295323539 (age 550.500s)
hex dump (first 64 bytes):
80 13 42 85 0b 00 ff ff ff ff
59 matches
Mail list logo
