All callers just use it to check if swiotlb is active at all, for which
they can just use is_swiotlb_active. In the longer run drivers need
to stop using is_swiotlb_active as well, but let's do the simple step
first.
Signed-off-by: Christoph Hellwig
---
Hi Konrad,
this series contains a bunch of swiotlb cleanups, mostly to reduce the
amount of internals exposed to code outside of swiotlb.c, which should
helper to prepare for supporting multiple different bounce buffer pools.
Changes since v2:
- fix a bisetion hazard that did not allocate the
> From: iommu On Behalf Of
> Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
>
> > 2. Consider ensuring that the problem is not somehow related to queued
> > invalidations. Try to use __iommu_flush_iotlb() instead of qi_flush_iotlb().
> >
>
> I tried to force to use
> -Original Message-
> From: Tian, Kevin [mailto:kevin.t...@intel.com]
> Sent: Thursday, March 18, 2021 4:27 PM
> To: Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
> ; Nadav Amit
> Cc: chenjiashang ; David Woodhouse
> ; iommu@lists.linux-foundation.org; LKML
> ;
On Fri, Mar 05, 2021 at 05:32:14PM +0800, Chunyan Zhang wrote:
> .../devicetree/bindings/iommu/sprd,iommu.yaml | 57 ++
> drivers/iommu/Kconfig | 12 +
> drivers/iommu/Makefile| 1 +
> drivers/iommu/sprd-iommu.c| 577
Instead of allocating ->list and ->orig_addr separately just do one
dynamic allocation for the actual io_tlb_mem structure. This simplifies
a lot of the initialization code, and also allows to just check
io_tlb_default_mem to see if swiotlb is in use.
Signed-off-by: Christoph Hellwig
---
From: Claire Chang
Added a new struct, io_tlb_mem, as the IO TLB memory pool descriptor and
moved relevant global variables into that struct.
This will be useful later to allow for restricted DMA pool.
Signed-off-by: Claire Chang
[hch: rebased]
Signed-off-by: Christoph Hellwig
---
Hi Suravee,
On Fri, Mar 12, 2021 at 03:04:08AM -0600, Suravee Suthikulpanit wrote:
> @@ -503,6 +504,7 @@ struct amd_io_pgtable {
> int mode;
> u64 *root;
> atomic64_t pt_root;/* pgtable root and pgtable mode */
> +
On Fri, Mar 12, 2021 at 03:04:10AM -0600, Suravee Suthikulpanit wrote:
> To allow specification whether to use v1 or v2 IOMMU pagetable for
> DMA remapping when calling kernel DMA-API.
>
> Signed-off-by: Suravee Suthikulpanit
> ---
> Documentation/admin-guide/kernel-parameters.txt | 6 ++
>
On 2021-03-18 11:38, John Garry wrote:
On 10/03/2021 17:47, John Garry wrote:
On 09/03/2021 15:55, John Garry wrote:
On 05/03/2021 16:35, Robin Murphy wrote:
Hi Robin,
When restarting after searching below the cached node fails, resetting
the start point to the anchor node is often overly
On Fri, Mar 12, 2021 at 03:04:11AM -0600, Suravee Suthikulpanit wrote:
> Introduce init function for setting up DMA domain for DMA-API with
> the IOMMU v2 page table.
>
> Signed-off-by: Suravee Suthikulpanit
> ---
> drivers/iommu/amd/iommu.c | 21 +
> 1 file changed, 21
Well yeah, in your particular case you're allocating from a heavily
over-contended address space, so much of the time it is genuinely full.
Plus you're primarily churning one or two sizes of IOVA, so there's a
high chance that you will either allocate immediately from the cached
node (after
On Fri, Mar 12, 2021 at 03:04:09AM -0600, Suravee Suthikulpanit wrote:
> @@ -519,6 +521,7 @@ struct protection_domain {
> spinlock_t lock;/* mostly used to lock the page table*/
> u16 id; /* the domain id written to the device table */
> int glx;
On Fri, Mar 05, 2021 at 04:35:22PM +, Robin Murphy wrote:
> Repeating the rb_entry() boilerplate all over the place gets old fast.
> Before adding yet more instances, add a little hepler to tidy it up.
>
> Signed-off-by: Robin Murphy
> ---
> drivers/iommu/iova.c | 23 ++-
On Fri, Mar 12, 2021 at 06:54:39PM +0300, Dmitry Osipenko wrote:
> The tegra_smmu_probe_device() handles only the first IOMMU device-tree
> phandle, skipping the rest. Devices like 3D module on Tegra30 have
> multiple IOMMU phandles, one for each h/w block, and thus, only one
> IOMMU phandle is
On Thu, Mar 18, 2021 at 11:21:24AM +0800, chenxiang wrote:
> From: Xiang Chen
>
> Fix a type "SAC" to "DAC" in the comment of function
> iommu_dma_alloc_iova().
>
> Signed-off-by: Xiang Chen
> ---
> drivers/iommu/dma-iommu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff
On Fri, Mar 05, 2021 at 04:32:34PM +, Robin Murphy wrote:
> In converting intel-iommu over to the common IOMMU DMA ops, it quietly
> lost the functionality of its "forcedac" option. Since this is a handy
> thing both for testing and for performance optimisation on certain
> platforms,
Hi will,
在 2021/3/18 17:34, Will Deacon 写道:
On Thu, Mar 18, 2021 at 11:21:24AM +0800, chenxiang wrote:
From: Xiang Chen
Fix a type "SAC" to "DAC" in the comment of function
iommu_dma_alloc_iova().
Signed-off-by: Xiang Chen
---
drivers/iommu/dma-iommu.c | 2 +-
1 file changed, 1
On 2021-03-16 19:16, Jean-Philippe Brucker wrote:
With the VIOT support in place, x86 platforms can now use the
virtio-iommu.
The arm64 Kconfig selects IOMMU_DMA, while x86 IOMMU drivers select it
themselves.
Actually, now that both AMD and Intel are converted over, maybe it's
finally time
Hi Nadav,
> -Original Message-
> From: Nadav Amit [mailto:nadav.a...@gmail.com]
> Sent: Thursday, March 18, 2021 2:13 AM
> To: Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
>
> Cc: David Woodhouse ; Lu Baolu
> ; Joerg Roedel ; w...@kernel.org;
> alex.william...@redhat.com;
> -Original Message-
> From: Tian, Kevin [mailto:kevin.t...@intel.com]
> Sent: Thursday, March 18, 2021 4:43 PM
> To: Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
> ; Nadav Amit
> Cc: chenjiashang ; David Woodhouse
> ; iommu@lists.linux-foundation.org; LKML
> ;
> -Original Message-
> From: Tian, Kevin [mailto:kevin.t...@intel.com]
> Sent: Thursday, March 18, 2021 4:56 PM
> To: Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
> ; Nadav Amit
> Cc: chenjiashang ; David Woodhouse
> ; iommu@lists.linux-foundation.org; LKML
> ;
Hi Baolu,
On Tue, Mar 09, 2021 at 08:46:41AM +0800, Lu Baolu wrote:
> The private data field of a page group response descriptor is set then
> immediately cleared in prq_event_thread(). Fix this by moving clearing
> code up.
>
> Fixes: 5b438f4ba315d ("iommu/vt-d: Support page request in scalable
> From: Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
>
>
>
> > -Original Message-
> > From: Tian, Kevin [mailto:kevin.t...@intel.com]
> > Sent: Thursday, March 18, 2021 4:27 PM
> > To: Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
> > ; Nadav Amit
> > Cc:
Dear Jörg, dear Suravee,
Am 03.03.21 um 15:10 schrieb Alexander Monakov:
On Wed, 3 Mar 2021, Suravee Suthikulpanit wrote:
Additionally, alternative proposed solutions [1] were not considered or
discussed.
From: Xiang Chen
Currently it only support one page map/unmap once a time for dma-map
benchmark, but there are some other scenaries which need to support for
multi-page map/unmap: for those multi-pages interfaces such as
dma_alloc_coherent() and dma_map_sg(), the time spent on multi-pages
> -Original Message-
> From: chenxiang (M)
> Sent: Thursday, March 18, 2021 10:30 PM
> To: h...@lst.de; m.szyprow...@samsung.com; robin.mur...@arm.com; Song Bao Hua
> (Barry Song)
> Cc: iommu@lists.linux-foundation.org; linux...@openeuler.org;
> linux-kselft...@vger.kernel.org;
On Thu, Mar 18, 2021 at 10:07:38AM +0100, j...@8bytes.org wrote:
> On Wed, Mar 17, 2021 at 07:14:17PM +, Derrick, Jonathan wrote:
> > Gentle reminder, for v5.13 ?
>
> This should go through the PCI tree, Bjorn?
I will start queuing code next week, noted.
Thanks,
Lorenzo
> From: Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
>
>
> > -Original Message-
> > From: Tian, Kevin [mailto:kevin.t...@intel.com]
> > Sent: Thursday, March 18, 2021 4:27 PM
> > To: Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
> > ; Nadav Amit
> > Cc:
On Wed, Mar 17, 2021 at 07:14:17PM +, Derrick, Jonathan wrote:
> Gentle reminder, for v5.13 ?
This should go through the PCI tree, Bjorn?
___
iommu mailing list
iommu@lists.linux-foundation.org
On Wed, Mar 17, 2021 at 06:48:50PM +0800, Huang Rui wrote:
> Series are Acked-by: Huang Rui
Thanks, series is applied for v5.12
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Thu, Mar 18, 2021 at 08:53:40AM +0800, Lu Baolu wrote:
> When the invalidation queue errors are encountered, dump the information
> logged by the VT-d hardware together with the pending queue invalidation
> descriptors.
>
> Signed-off-by: Ashok Raj
> Tested-by: Guo Kaijie
> Signed-off-by: Lu
On Wed, Mar 17, 2021 at 08:58:34AM +0800, Lu Baolu wrote:
> The pasid_lock is used to synchronize different threads from modifying a
> same pasid directory entry at the same time. It causes below lockdep splat.
>
> [ 83.296538]
> [
On Tue, Mar 16, 2021 at 08:16:54PM +0100, Jean-Philippe Brucker wrote:
> With the VIOT support in place, x86 platforms can now use the
> virtio-iommu.
>
> The arm64 Kconfig selects IOMMU_DMA, while x86 IOMMU drivers select it
> themselves.
>
> Signed-off-by: Jean-Philippe Brucker
> ---
>
On 2021-03-18 09:55, chenxiang (M) wrote:
Hi will,
在 2021/3/18 17:34, Will Deacon 写道:
On Thu, Mar 18, 2021 at 11:21:24AM +0800, chenxiang wrote:
From: Xiang Chen
Fix a type "SAC" to "DAC" in the comment of function
iommu_dma_alloc_iova().
Signed-off-by: Xiang Chen
---
Hi,
On Mon, Mar 08, 2021 at 11:47:46AM -0800, Raj, Ashok wrote:
> That is the primary motivation, given that we have moved to 1st level for
> general IOVA, first level doesn't have a WO mapping. I didn't know enough
> about the history to determine if a WO without a READ is very useful. I
> guess
On Wed, Mar 03, 2021 at 05:36:11PM +, Shameer Kolothum wrote:
> The device iommu probe/attach might have failed leaving dev->iommu
> to NULL and device drivers may still invoke these functions resulting
> in a crash in iommu vendor driver code.
>
> Hence make sure we check that.
>
> Fixes:
On Sun, Mar 14, 2021 at 01:15:34PM -0700, Kyung Min Park wrote:
> Currently, the Intel VT-d supports Shared Virtual Memory (SVM) only when
> IO page fault is supported. Otherwise, shared memory pages can not be
> swapped out and need to be pinned. The device needs the Address Translation
> Service
On Tue, Mar 02, 2021 at 02:13:56AM -0800, Jacob Pan wrote:
> Hi Baolu et al,
>
> This is a collection of SVA-related fixes.
>
> ChangeLog:
>
> v2:
> - For guest SVA, call pasid_set_wpe directly w/o checking host CR0.wp
> (Review comments by Kevin T.)
> - Added fixes tag
>
>
On 10/03/2021 17:47, John Garry wrote:
On 09/03/2021 15:55, John Garry wrote:
On 05/03/2021 16:35, Robin Murphy wrote:
Hi Robin,
When restarting after searching below the cached node fails, resetting
the start point to the anchor node is often overly pessimistic. If
allocations are made with
On 3/18/2021 12:18 PM, Florian Fainelli wrote:
> It may be useful to disable the SWIOTLB completely for testing or when a
> platform is known not to have any DRAM addressing limitations what so
> ever.
>
> Signed-off-by: Florian Fainelli
Christoph, in addition to this change, how would you
On 2021-03-18 21:31, Florian Fainelli wrote:
On 3/18/2021 12:53 PM, Robin Murphy wrote:
On 2021-03-18 19:43, Florian Fainelli wrote:
On 3/18/2021 12:34 PM, Robin Murphy wrote:
On 2021-03-18 19:22, Florian Fainelli wrote:
On 3/18/2021 12:18 PM, Florian Fainelli wrote:
It may be useful
On 3/18/2021 12:53 PM, Robin Murphy wrote:
> On 2021-03-18 19:43, Florian Fainelli wrote:
>>
>>
>> On 3/18/2021 12:34 PM, Robin Murphy wrote:
>>> On 2021-03-18 19:22, Florian Fainelli wrote:
On 3/18/2021 12:18 PM, Florian Fainelli wrote:
> It may be useful to disable the
On 2021-03-16 19:16, Jean-Philippe Brucker wrote:
The ACPI Virtual I/O Translation Table describes topology of
para-virtual platforms. For now it describes the relation between
virtio-iommu and the endpoints it manages. Supporting that requires
three steps:
(1) acpi_viot_init(): parse the VIOT
It may be useful to disable the SWIOTLB completely for testing or when a
platform is known not to have any DRAM addressing limitations what so
ever.
Signed-off-by: Florian Fainelli
---
Documentation/admin-guide/kernel-parameters.txt | 1 +
include/linux/swiotlb.h | 1 +
> On Mar 18, 2021, at 2:25 AM, Longpeng (Mike, Cloud Infrastructure Service
> Product Dept.) wrote:
>
>
>
>> -Original Message-
>> From: Tian, Kevin [mailto:kevin.t...@intel.com]
>> Sent: Thursday, March 18, 2021 4:56 PM
>> To: Longpeng (Mike, Cloud Infrastructure Service Product
On Tue, Mar 16, 2021 at 08:16:54PM +0100, Jean-Philippe Brucker wrote:
> With the VIOT support in place, x86 platforms can now use the
> virtio-iommu.
>
> The arm64 Kconfig selects IOMMU_DMA, while x86 IOMMU drivers select it
> themselves.
>
> Signed-off-by: Jean-Philippe Brucker
Acked-by:
On 2021-03-18 19:22, Florian Fainelli wrote:
On 3/18/2021 12:18 PM, Florian Fainelli wrote:
It may be useful to disable the SWIOTLB completely for testing or when a
platform is known not to have any DRAM addressing limitations what so
ever.
Isn't that what "swiotlb=noforce" is for? If
On 3/18/2021 12:34 PM, Robin Murphy wrote:
> On 2021-03-18 19:22, Florian Fainelli wrote:
>>
>>
>> On 3/18/2021 12:18 PM, Florian Fainelli wrote:
>>> It may be useful to disable the SWIOTLB completely for testing or when a
>>> platform is known not to have any DRAM addressing limitations what so
Hi Jean,
On 3/16/21 8:16 PM, Jean-Philippe Brucker wrote:
> Just here for reference, don't merge!
>
> The actual commits will be pulled from the next ACPICA release.
> I squashed the three relevant commits:
>
> ACPICA commit fc4e33319c1ee08f20f5c44853dd8426643f6dfd
> ACPICA commit
On 2021-03-18 19:43, Florian Fainelli wrote:
On 3/18/2021 12:34 PM, Robin Murphy wrote:
On 2021-03-18 19:22, Florian Fainelli wrote:
On 3/18/2021 12:18 PM, Florian Fainelli wrote:
It may be useful to disable the SWIOTLB completely for testing or when a
platform is known not to have any
Hi,
在 2021/3/18 19:01, Robin Murphy 写道:
On 2021-03-18 09:55, chenxiang (M) wrote:
Hi will,
在 2021/3/18 17:34, Will Deacon 写道:
On Thu, Mar 18, 2021 at 11:21:24AM +0800, chenxiang wrote:
From: Xiang Chen
Fix a type "SAC" to "DAC" in the comment of function
iommu_dma_alloc_iova().
Hi Joerg,
On 3/18/21 6:10 PM, Joerg Roedel wrote:
Hi Baolu,
On Tue, Mar 09, 2021 at 08:46:41AM +0800, Lu Baolu wrote:
The private data field of a page group response descriptor is set then
immediately cleared in prq_event_thread(). Fix this by moving clearing
code up.
Fixes: 5b438f4ba315d
On Thu, Mar 18, 2021 at 09:00:54PM -0700, Florian Fainelli wrote:
> When SWIOTLB_NO_FORCE is used, there should really be no allocations of
> io_tlb_nslabs to occur since we are not going to use those slabs. If a
> platform was somehow setting swiotlb_no_force and a later call to
> swiotlb_init()
On 3/18/2021 4:35 PM, Robin Murphy wrote:
> On 2021-03-18 21:31, Florian Fainelli wrote:
>>
>>
>> On 3/18/2021 12:53 PM, Robin Murphy wrote:
>>> On 2021-03-18 19:43, Florian Fainelli wrote:
On 3/18/2021 12:34 PM, Robin Murphy wrote:
> On 2021-03-18 19:22, Florian Fainelli
We do not need a SWIOTLB unless we have DRAM that is addressable beyond
the arm_dma_limit. Compare max_pfn with arm_dma_pfn_limit to determine
whether we do need a SWIOTLB to be initialized.
Fixes: ad3c7b18c5b3 ("arm: use swiotlb for bounce buffering on LPAE configs")
Signed-off-by: Florian
On 3/18/21 4:56 PM, Tian, Kevin wrote:
From: Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
-Original Message-
From: Tian, Kevin [mailto:kevin.t...@intel.com]
Sent: Thursday, March 18, 2021 4:27 PM
To: Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
; Nadav
Hi Joerg,
On 3/18/21 5:12 PM, Joerg Roedel wrote:
Hi,
On Mon, Mar 08, 2021 at 11:47:46AM -0800, Raj, Ashok wrote:
That is the primary motivation, given that we have moved to 1st level for
general IOVA, first level doesn't have a WO mapping. I didn't know enough
about the history to determine
Hi Joerg,
On 3/18/21 6:21 PM, Joerg Roedel wrote:
On Wed, Mar 17, 2021 at 08:58:34AM +0800, Lu Baolu wrote:
The pasid_lock is used to synchronize different threads from modifying a
same pasid directory entry at the same time. It causes below lockdep splat.
[ 83.296538]
Hi Jean,
Slightly off the title. As we are moving to use cgroup to limit PASID
allocations, it would be much simpler if we enforce on the current task.
However, iommu_sva_alloc_pasid() takes an mm_struct pointer as argument
which implies it can be something other the the current task mm. So far
> >
> > In fact I should have looked more closely at that myself - checking
> > debugfs on my 4GB arm64 board actually shows io_tlb_nslabs = 0, and
> > indeed we are bypassing initialisation completely and (ab)using
> > SWIOTLB_NO_FORCE to cover it up, so I guess it probably *is* safe now
> > for
When SWIOTLB_NO_FORCE is used, there should really be no allocations of
io_tlb_nslabs to occur since we are not going to use those slabs. If a
platform was somehow setting swiotlb_no_force and a later call to
swiotlb_init() was to be made we would still be proceeding with
allocating the default
> On Mar 17, 2021, at 9:46 PM, Longpeng (Mike, Cloud Infrastructure Service
> Product Dept.) wrote:
>
[Snip]
>
> NOTE, the magical thing happen...(*Operation-4*) we write the PTE
> of Operation-1 from 0 to 0x3 which means can Read/Write, and then
> we trigger DMA read again, it success and
63 matches
Mail list logo
