s to deal with special cases like this.
Signed-off-by: Qian Cai
---
kernel/dma/debug.c | 9 ++---
lib/Kconfig.debug | 9 +
2 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/kernel/dma/debug.c b/kernel/dma/debug.c
index 231ca4628062..3752fb23f72f 100644
--- a/kernel/dma/de
(i = 0; i < handle->q_num; i++)
[2] for (i = 0; i < ring->desc_num; i++)
On this Huawei TaiShan 2280 aarch64 server, it has reached the limit
already,
4 (ports) x 16 (handles) x 1024 (rings) = 65536
Signed-off-by: Qian Cai
---
kernel/dma/debug.c | 5 +
1 file changed, 5 ins
) = 65536
Added a Kconfig entry for PREALLOC_DMA_DEBUG_ENTRIES, so make it easier
for users to deal with special cases like this.
Signed-off-by: Qian Cai
---
Changes since v1:
* Increased the default value if has HNS_ENET suggested by Robin.
kernel/dma/debug.c | 9 ++---
lib/Kconfig.debug | 10 ++
2 fi
| 7 -
> kernel/dma/debug.c | 217 ++
> 5 files changed, 109 insertions(+), 163 deletions(-)
>
Tested-by: Qian Cai
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Mon, 2019-06-03 at 14:07 +0100, Robin Murphy wrote:
> On 03/06/2019 13:59, Qian Cai wrote:
> > There are a few macros in IOMMU have single-char identifiers make the
> > code hard to read and debug. Replace them with meaningful names.
> >
> > Suggested-by: Andrew Mort
_acpi_namespace_devices':
drivers/iommu/intel-iommu.c:4639:22: warning: variable 'iommu' set but
not used [-Wunused-but-set-variable]
struct intel_iommu *iommu;
Silence the warning the same way as in the commit d3ed71e5cc50
("drivers/iommu/intel-iommu.c: fix variable 'iommu' set but not used&qu
There are a few macros in DMA have single-char identifiers make the code
hard to read. Replace them with meaningful names.
Signed-off-by: Qian Cai
---
include/linux/dma-mapping.h | 24
include/linux/dmar.h| 14 --
2 files changed, 24 insertions
The commit "iommu/vt-d: Delegate the dma domain to upper layer" left an
unused variable,
drivers/iommu/intel-iommu.c: In function 'disable_dmar_iommu':
drivers/iommu/intel-iommu.c:1652:23: warning: variable 'domain' set but
not used [-Wunused-but-set-variable]
Signed-off-by
The linux-next series "iommu/vt-d: Delegate DMA domain to generic iommu" [1]
causes a system with the rootfs on megaraid_sas card unable to boot.
Reverted the whole series on the top of linux-next (next-20190607) fixed the
issue.
The information regards this storage card is,
[ 116.466810][
main attach due to platform RMRR requirement. Contact your platform
> vendor.
> [ 101.900801] pci :06:00.0: Failed to add to iommu group 23: -1
>
> Best regards,
> Baolu
>
> On 6/10/19 10:54 PM, Qian Cai wrote:
>> On Mon, 2019-06-10 at 09:44 -0400, Qian Cai wrote:
On Sun, 2019-06-09 at 10:37 +0800, Lu Baolu wrote:
> Hi Joerg,
>
> This series includes several fixes and cleanups after delegating
> DMA domain to generic iommu. Please review and consider them for
> linux-next.
>
> Best regards,
> Baolu
>
> Lu Baolu (5):
> iommu/vt-d: Don't return error
iable]
[1] https://lore.kernel.org/patchwork/patch/1083073/
Signed-off-by: Qian Cai
---
drivers/iommu/intel-iommu.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 478ac186570b..d86d4ee5cc78 100644
--- a/drivers/iommu/intel-iom
On Mon, 2019-06-10 at 09:44 -0400, Qian Cai wrote:
> On Sun, 2019-06-09 at 10:43 +0800, Lu Baolu wrote:
> > Hi Qian,
> >
> > I just posted some fix patches. I cc'ed them in your email inbox as
> > well. Can you please check whether they happen to fix your issue?
>
On Sun, 2019-06-09 at 10:43 +0800, Lu Baolu wrote:
> Hi Qian,
>
> I just posted some fix patches. I cc'ed them in your email inbox as
> well. Can you please check whether they happen to fix your issue?
> If not, do you mind posting more debug messages?
Unfortunately, it does not work. Here is
mapping':
drivers/iommu/intel-iommu.c:3037:22: warning: variable 'iommu' set but
not used [-Wunused-but-set-variable]
struct intel_iommu *iommu;
Fixed the warning by appending a compiler attribute __maybe_unused for it.
Suggested-by: Andrew Morton
Signed-off-by: Qian Cai
---
drivers/iommu/intel-
mapping':
drivers/iommu/intel-iommu.c:3037:22: warning: variable 'iommu' set but
not used [-Wunused-but-set-variable]
struct intel_iommu *iommu;
Fixed the warning by passing "drhd->iommu" directly to
for_each_active_iommu() which all subsequent self-assignments should be
ignored by a c
mapping':
drivers/iommu/intel-iommu.c:3037:22: warning: variable 'iommu' set but not
used [-Wunused-but-set-variable]
struct intel_iommu *iommu;
Fixed the warning by passing "drhd->iommu" directly to
for_each_active_iommu() which all subsequent self-assignments should be
ignored by a c
On Tue, 2019-05-07 at 13:47 +, Gary R Hook wrote:
> On 5/5/19 11:11 PM, Qian Cai wrote:
> > [CAUTION: External Email]
> >
> > The commit e7f63ffc1bf1 ("iommu/amd: Update logging information for new
> > event type") introduced a variable "tag&
On 4/29/19 10:23 AM, Joerg Roedel wrote:
> On Fri, Apr 26, 2019 at 11:55:12AM -0400, Qian Cai wrote:
>> https://git.sr.ht/~cai/linux-debug/blob/master/dmesg
>
> Thanks, I can't see any definitions for unity ranges or exclusion ranges
> in the IVRS table dump, which makes
: variable 'tag' set but not
used [-Wunused-but-set-variable]
int type, devid, pasid, flags, tag;
^~~
so just use it during the logging.
Signed-off-by: Qian Cai
---
drivers/iommu/amd_iommu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers
On 4/26/19 10:52 AM, Qian Cai wrote:
> Applying some memory pressure would causes smartpqi offline even in today's
> linux-next. This can always be reproduced by a LTP test cases [1] or sometimes
> just compiling kernels.
>
> Reverting the commit "iommu/amd: Set exclusion ra
it+0x149e/0x14df [smartpqi]
pqi_pci_probe.cold.49+0x808/0x818 [smartpqi]
local_pci_probe+0x7a/0xc0
work_for_cpu_fn+0x2e/0x50
process_one_work+0x522/0xa10
worker_thread+0x363/0x5b0
kthread+0x1d2/0x1f0
ret_from_fork+0x22/0x40
Signed-off-by: Qian Cai
---
drivers/iommu/amd_iommu.c | 3 ++-
1 file c
fork+0x22/0x40
Signed-off-by: Qian Cai
---
v2: Call domain_flush_np_cache() inside for_each_sg().
drivers/iommu/amd_iommu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 867f8b155000..b7132812ce59 100644
--- a/drive
On Mon, 2019-04-29 at 16:23 +0200, Joerg Roedel wrote:
> On Fri, Apr 26, 2019 at 11:55:12AM -0400, Qian Cai wrote:
> > https://git.sr.ht/~cai/linux-debug/blob/master/dmesg
>
> Thanks, I can't see any definitions for unity ranges or exclusion ranges
> in the IVRS table dump, w
/0x5b0
kthread+0x1d2/0x1f0
ret_from_fork+0x22/0x40
Fix it by validating the return from the 2nd alloc_iova_fast() in
dma_ops_alloc_iova(), so map_sg() could handle the error condition
immediately.
Signed-off-by: Qian Cai
---
drivers/iommu/amd_iommu.c | 2 ++
1 file changed, 2 insertions(+)
+0x27/0x30
process_one_work+0x522/0xa10
worker_thread+0x63/0x5b0
kthread+0x1d2/0x1f0
ret_from_fork+0x22/0x40
Fixes: b3aa14f02254 ("iommu: remove the mapping_error dma_map_ops method")
Signed-off-by: Qian Cai
---
v2: Fix the offensive commit directly.
drivers/i
Applying some memory pressure would causes smartpqi offline even in today's
linux-next. This can always be reproduced by a LTP test cases [1] or sometimes
just compiling kernels.
Reverting the commit "iommu/amd: Set exclusion range correctly" fixed the issue.
[ 213.437112] smartpqi
On Fri, 2019-04-26 at 17:26 +0200, Joerg Roedel wrote:
> On Fri, Apr 26, 2019 at 10:52:28AM -0400, Qian Cai wrote:
> > Applying some memory pressure would causes smartpqi offline even in today's
> > linux-next. This can always be reproduced by a LTP test cases [1] or
> &g
The linux-next commit “iommu/arm-smmu-v3: Rework enabling/disabling of ATS for
PCI masters” [1] causes a compilation error when PCI_ATS=n on arm64.
[1] https://lore.kernel.org/linux-iommu/20190820154549.17018-3-w...@kernel.org/
drivers/iommu/arm-smmu-v3.c:2325:35: error: no member named
in this call site, and there is still a
dev_err() later to notify the failure.
Signed-off-by: Qian Cai
---
drivers/iommu/amd_iommu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index b607a92791d3..19eef1edf8ed 100644
On Thu, 2019-09-05 at 13:43 +0200, Joerg Roedel wrote:
> Hi Qian,
>
> On Wed, Sep 04, 2019 at 05:24:22PM -0400, Qian Cai wrote:
> > if (domain->mode == PAGE_MODE_6_LEVEL)
> > /* address space already 64 bit large */
> > return fal
When the system is under some memory pressure, it could cause disks on
the "smartpqi" driver going offline below. From the UBSAN report, it
indicates that "domain->mode" becomes 7. Further investigation indicates
that the only place that would increase "domain->mode" is
increase_address_space()
On Fri, 2019-09-13 at 12:48 +0100, Robin Murphy wrote:
> Although CONFIG_ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT is a welcome tool
> for smoking out inadequate firmware, the failure mode is non-obvious
> and can be confusing for end users. Add some special-case reporting of
> Unidentified Stream Faults
On Tue, 2019-09-10 at 10:15 +0200, Joerg Roedel wrote:
> On Sat, Sep 07, 2019 at 04:49:33PM +1000, Adam Zerella wrote:
> > drivers/iommu/intel-iommu.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
>
> Applied, thanks.
Joerg, not sure if you saw the reply from Lu,
he -Wunused-function compilation warning.
Signed-off-by: Qian Cai
---
kernel/dma/coherent.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/kernel/dma/coherent.c b/kernel/dma/coherent.c
index 29fd6590dc1e..909b38e1c29b 100644
--- a/kernel/dma/coherent.c
+++ b/kernel/dma/coherent.c
@@ -28,15 +2
> On Nov 10, 2019, at 8:30 PM, Lu Baolu wrote:
>
> How about "pasid based multiple stages DMA translation"?
It is better but I am still not sure how developers should select it or not
when asking. Ideally, should it mention pros and cons of this? At minimal,
there should be a line said “if
> On Nov 8, 2019, at 10:43 PM, Lu Baolu wrote:
>
> +config INTEL_IOMMU_SCALABLE_MODE_DEFAULT_ON
> +prompt "Enable Intel IOMMU scalable mode by default"
> +depends on INTEL_IOMMU
> +help
> + Selecting this option will enable the scalable mode if
> + hardware presents the
> On Nov 8, 2019, at 10:40 PM, Lu Baolu wrote:
>
> This adds Kconfig option INTEL_IOMMU_SCALABLE_MODE_DEFAULT_ON
> to make it easier for distributions to enable or disable the
> Intel IOMMU scalable mode by default during kernel build.
>
> Signed-off-by: Lu Baolu
> ---
>
> On Nov 11, 2019, at 12:23 AM, Lu Baolu wrote:
>
> The scalable mode is defined in VT-d 3.0. The scalable mode capability
> could be checked by reading /sys/devices/virtual/iommu/dmar*/intel-
> iommu/ecap. It's currently not friendly for reading. You need to decode
> it according to the
On Fri, 2019-11-22 at 08:28 -0800, Joe Perches wrote:
> On Fri, 2019-11-22 at 09:59 -0500, Qian Cai wrote:
> > On Thu, 2019-11-21 at 20:37 -0800, Joe Perches wrote:
> > > On Thu, 2019-11-21 at 21:55 -0500, Qian Cai wrote:
> > > > When running heavy memory pressure
On Thu, 2019-11-21 at 20:37 -0800, Joe Perches wrote:
> On Thu, 2019-11-21 at 21:55 -0500, Qian Cai wrote:
> > When running heavy memory pressure workloads, this 5+ old system is
> > throwing endless warnings below because disk IO is too slow to recover
> > from swapping.
Read files under /sys/kernel/iommu_groups/ triggers an use-after-free. Reverted
the commit 4dbd258ff63e ("iommu: Revisit iommu_insert_resv_region()
implementation") fixed the issue.
/* no merge needed on elements of different types than @nr */
if (iter->type != nr->type) {
ble:453879
mapped:2380 shmem:154 pagetables:6948 bounce:0
free:19133 free_pcp:7363 free_cma:0
Signed-off-by: Qian Cai
---
v3: insert a "\n" in dev_err_ratelimited() per Joe.
v2: use dev_err_ratelimited() and improve the commit messages.
drivers/iommu/intel-iommu.c | 3 ++-
iteback:5 unstable:0
slab_reclaimable:13972 slab_unreclaimable:453879
mapped:2380 shmem:154 pagetables:6948 bounce:0
free:19133 free_pcp:7363 free_cma:0
Signed-off-by: Qian Cai
---
v4: use dev_err_once() instead as mentioned above.
v3: insert a "\n" in dev_err_ratelimited() per Jo
ble:453879
mapped:2380 shmem:154 pagetables:6948 bounce:0
free:19133 free_pcp:7363 free_cma:0
Signed-off-by: Qian Cai
---
v2: use dev_err_ratelimited() and improve the commit messages.
drivers/iommu/intel-iommu.c | 3 ++-
drivers/iommu/iova.c| 2 +-
2 files changed, 3 insert
> On Dec 6, 2019, at 4:38 PM, Cong Wang wrote:
>
> This patchset contains three small optimizations for the global spinlock
> contention in IOVA cache. Our memcache perf test shows this reduced its
> p999 latency down by 45% on AMD when IOMMU is enabled.
Can you at least have a changelog
bd258ff63e ("iommu: Revisit iommu_insert_resv_region()
> implementation")
> Signed-off-by: Eric Auger
> Reported-by: Qian Cai
> Cc: Stable #v5.3+
Looks like Joerg is away for a few weeks. Could Andrew or Linus pick up this
use-after-free?
>
> ---
>
> v2 -> v3:
&
On Wed, 2019-10-16 at 17:31 +0200, Joerg Roedel wrote:
> Hi Qian,
>
> thanks for the report!
>
> On Wed, Oct 16, 2019 at 10:59:42AM -0400, Qian Cai wrote:
> > On Wed, 2019-10-16 at 10:55 -0400, Qian Cai wrote:
> > > Today's linux-next generates a lot of warni
On Wed, 2019-10-16 at 18:03 +0200, Joerg Roedel wrote:
> On Wed, Oct 16, 2019 at 11:53:33AM -0400, Qian Cai wrote:
> > On Wed, 2019-10-16 at 17:31 +0200, Joerg Roedel wrote:
> > The x86 one might just be a mistake.
> >
> > diff --git a/drivers/iommu/amd_iommu.c
ug_list+0x448/0x7e0
blk_flush_plug_list+0x1eb/0x230
blk_finish_plug+0x43/0x5d
shrink_node_memcg+0x9c5/0x1550
smartpqi :23:00.0: controller is offline: status code 0x14803
smartpqi :23:00.0: controller offline
Fixes: 754265bcab78 ("iommu/amd: Fix race in increase_address_space()")
S
On Wed, 2019-10-16 at 17:44 +0200, Joerg Roedel wrote:
> On Wed, Oct 16, 2019 at 10:59:42AM -0400, Qian Cai wrote:
> > BTW, the previous x86 warning was from only reverted one patch "iommu: Add
> > gfp
> > parameter to iommu_ops::map" where proved t
> On Oct 16, 2019, at 6:59 PM, Jerry Snitselaar wrote:
>
> I guess the mode level 6 check is really for other potential callers
> increase_address_space, none exist at the moment, and the condition
> of the while loop in alloc_pte should fail if the mode level is 6.
Because there is no
Today's linux-next generates a lot of warnings on multiple servers during boot
due to the series "iommu/amd: Convert the AMD iommu driver to the dma-iommu api"
[1]. Reverted the whole things fixed them.
[1] https://lore.kernel.org/lkml/20190908165642.22253-1-murph...@tcd.ie/
[ 257.785749][
On Wed, 2019-10-16 at 10:55 -0400, Qian Cai wrote:
> Today's linux-next generates a lot of warnings on multiple servers during boot
> due to the series "iommu/amd: Convert the AMD iommu driver to the dma-iommu
> api"
> [1]. Reverted the whole things fixed them.
>
>
> On Nov 27, 2019, at 1:01 PM, John Garry wrote:
>
> I haven't gone into the details, but this patch alone is giving this:
>
> root@(none)$ [ 123.857024] kmemleak: 8 new suspected memory leaks (see
> /sys/kernel/debug/kmemleak)
>
> root@(none)$ cat /sys/kernel/debug/kmemleak
>
Ping. Please take a look at this trivial patch.
On Tue, 2019-09-17 at 09:00 -0400, Qian Cai wrote:
> dma_get_device_base() was first introduced in the commit c41f9ea998f3
> ("drivers: dma-coherent: Account dma_pfn_offset when used with device
> tree"). Later, it was re
kernel_init+0x11/0x139
ret_from_fork+0x3a/0x50
DMAR: Intel(R) Virtualization Technology for Directed I/O
Fixes: d8190dc63886 ("iommu/vt-d: Enable DMA remapping after rmrr mapped")
Signed-off-by: Qian Cai
---
drivers/iommu/intel-iommu.c | 5 -
1 file changed, 4 insertions(+), 1 deletio
lobal_lock){+.+.}, at:
intel_iommu_init+0x125/0xb97
drivers/iommu/intel-iommu.c:5057 RCU-list traversed in non-reader section!!
1 lock held by swapper/0/1:
#0: a71892c8 (dmar_global_lock){}, at:
intel_iommu_init+0x61a/0xb13
Signed-off-by: Qian Cai
---
drivers/iommu/dmar.c | 3 ++
]
struct iommu_dma_cookie *cookie;
^~
Fixes: c18647900ec8 ("iommu/dma: Relax locking in iommu_dma_prepare_msi()")
Signed-off-by: Qian Cai
---
drivers/iommu/dma-iommu.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drive
> On Jan 6, 2020, at 1:19 PM, Robin Murphy wrote:
>
> Fair enough... I guess this is a W=1 thing?
Yes.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
> On Apr 13, 2020, at 9:36 PM, Qian Cai wrote:
>
>
>
>> On Apr 8, 2020, at 10:19 AM, Joerg Roedel wrote:
>>
>> Hi Qian,
>>
>> On Tue, Apr 07, 2020 at 11:36:05AM -0400, Qian Cai wrote:
>>> After further testing, the change along is
> On Apr 18, 2020, at 8:10 AM, Joerg Roedel wrote:
>
> Yes, your patch still looks racy. You need to atomically read
> domain->pt_root to a stack variable and derive the pt_root pointer and
> the mode from that variable instead of domain->pt_root directly. If you
> read the domain->pt_root
> On Apr 6, 2020, at 10:12 PM, Qian Cai wrote:
>
> fetch_pte() could race with increase_address_space() because it held no
> lock from iommu_unmap_page(). On the CPU that runs fetch_pte() it could
> see a stale domain->pt_root and a new increased domain->mode from
>
> On Apr 8, 2020, at 10:19 AM, Joerg Roedel wrote:
>
> Hi Qian,
>
> On Tue, Apr 07, 2020 at 11:36:05AM -0400, Qian Cai wrote:
>> After further testing, the change along is insufficient. What I am chasing
>> right
>> now is the swap device will go offline
> On Apr 18, 2020, at 2:34 PM, Joerg Roedel wrote:
>
> On Sat, Apr 18, 2020 at 09:01:35AM -0400, Qian Cai wrote:
>> Hard to tell without testing further. I’ll leave that optimization in
>> the future, and focus on fixing those races first.
>
> Yeah right, we sh
> On Apr 18, 2020, at 2:34 PM, Joerg Roedel wrote:
>
> On Sat, Apr 18, 2020 at 09:01:35AM -0400, Qian Cai wrote:
>> Hard to tell without testing further. I’ll leave that optimization in
>> the future, and focus on fixing those races first.
>
> Yeah right, we sh
cpu+0x70/0x100
handle_irq_event+0x5a/0x8b
handle_edge_irq+0x10c/0x370
do_IRQ+0x9e/0x1e0
common_interrupt+0xf/0xf
Signed-off-by: Qian Cai
---
drivers/iommu/amd_iommu.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
inde
> On May 3, 2020, at 2:39 PM, Joerg Roedel wrote:
>
> Can I add your Tested-by when I
> send them to the mailing list tomorrow?
Sure. Feel free to add,
Tested-by: Qian Cai
___
iommu mailing list
iommu@lists.linux-foundati
> On Apr 29, 2020, at 7:20 AM, Joerg Roedel wrote:
>
> On Mon, Apr 20, 2020 at 09:26:12AM -0400, Qian Cai wrote:
>> No dice. There could be some other races. For example,
>
> Can you please test this branch:
>
>
> https://git.kernel.org/pub/scm/linux/ke
> On Mar 18, 2020, at 1:27 AM, Lu Baolu wrote:
>
> How about changing the commit subject to
> "iommu/vt-d: Silence RCU-list debugging warning in dmar_find_atsr()"?
Just a bit long which should be non-issue.
___
iommu mailing list
+0x1a/0x44
do_one_initcall+0xae/0x4d0
kernel_init_freeable+0x412/0x4c5
kernel_init+0x19/0x193
Signed-off-by: Qian Cai
---
drivers/iommu/intel-iommu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index
]
struct amd_iommu *iommu;
^
Signed-off-by: Qian Cai
---
drivers/iommu/amd_iommu.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index fef3689ee535..2b8eb58d2bea 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/dri
The commit 6ee1b77ba3ac ("iommu/vt-d: Add svm/sva invalidate function")
introduced a GCC warning,
drivers/iommu/intel-iommu.c:5330:1: warning: 'static' is not at beginning of
declaration [-Wold-style-declaration]
const static int
^
Signed-off-by: Qian Cai
---
drivers/iommu/int
> On Apr 29, 2020, at 7:20 AM, Joerg Roedel wrote:
>
> On Mon, Apr 20, 2020 at 09:26:12AM -0400, Qian Cai wrote:
>> No dice. There could be some other races. For example,
>
> Can you please test this branch:
>
>
> https://git.kernel.org/pub/scm/linux/ke
On Wed, 2020-08-26 at 13:17 +0200, Thomas Gleixner wrote:
> From: Thomas Gleixner
>
> The arch_.*_msi_irq[s] fallbacks are compiled in whether an architecture
> requires them or not. Architectures which are fully utilizing hierarchical
> irq domains should never call into that code.
>
> It's
On Wed, 2020-08-26 at 13:16 +0200, Thomas Gleixner wrote:
> This is the second version of providing a base to support device MSI (non
> PCI based) and on top of that support for IMS (Interrupt Message Storm)
> based devices in a halfways architecture independent way.
>
> The first version can be
On Tue, Jun 30, 2020 at 08:40:28PM -0400, Qian Cai wrote:
> On Wed, Apr 29, 2020 at 03:36:38PM +0200, Joerg Roedel wrote:
> > Hi,
> >
> > here is the third version of this patch-set. Older versions can be found
> > here:
> >
> > v1: https://lore.
nd release_device()
call-backs")
Signed-off-by: Qian Cai
---
drivers/iommu/iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 1ed1e14a1f0c..0eeb3251266a 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -
On Wed, Apr 29, 2020 at 03:36:38PM +0200, Joerg Roedel wrote:
> Hi,
>
> here is the third version of this patch-set. Older versions can be found
> here:
>
> v1: https://lore.kernel.org/lkml/20200407183742.4344-1-j...@8bytes.org/
> (Has some more introductory text)
>
> v2:
On Thu, Jun 25, 2020 at 04:52:27PM +0200, Joerg Roedel wrote:
> From: Joerg Roedel
>
> Using atomic64_t can be quite expensive, so use unsigned long instead.
> This is safe because the write becomes visible atomically.
>
> Signed-off-by: Joerg Roedel
> ---
>
> On Jun 26, 2020, at 4:05 AM, Joerg Roedel wrote:
>
> a previous discussion pointed out that using atomic64_t for that
> purpose is a bit of overkill. This patch-set replaces it with unsigned
> long and introduces some helpers first to make the change more easy.
BTW, from the previous
On Sat, 2020-10-24 at 22:35 +0100, David Woodhouse wrote:
> From: Thomas Gleixner
>
> 'trigger' and 'polarity' are used throughout the I/O-APIC code for handling
> the trigger type (edge/level) and the active low/high configuration. While
> there are defines for initializing these variables and
On 6/18/2021 11:40 PM, Claire Chang wrote:
> Propagate the swiotlb_force into io_tlb_default_mem->force_bounce and
> use it to determine whether to bounce the data or not. This will be
> useful later to allow for different pools.
>
> Signed-off-by: Claire Chang
> Reviewed-by: Christoph
On 6/23/2021 2:37 PM, Will Deacon wrote:
> On Wed, Jun 23, 2021 at 12:39:29PM -0400, Qian Cai wrote:
>>
>>
>> On 6/18/2021 11:40 PM, Claire Chang wrote:
>>> Propagate the swiotlb_force into io_tlb_default_mem->force_bounce and
>>> use
On 6/24/2021 7:48 AM, Will Deacon wrote:
> Ok, diff below which attempts to tackle the offset issue I mentioned as
> well. Qian Cai -- please can you try with these changes?
This works fine.
>
> Will
>
> --->8
>
> diff --git a/include/linux/swiotlb.h b/incl
On Mon, Apr 18, 2022 at 08:49:49AM +0800, Lu Baolu wrote:
> Hi Joerg,
>
> This is a resend version of v8 posted here:
> https://lore.kernel.org/linux-iommu/20220308054421.847385-1-baolu...@linux.intel.com/
> as we discussed in this thread:
>
86 matches
Mail list logo
