When a device is initialized, the driver invokes dma_supported() twice - first
for streaming mappings followed by coherent mappings. For an SR-IOV device,
default window is deleted and DDW created. With vPMEM enabled, TCE mappings
are dynamically created for both vPMEM and SR-IOV device. There are
DW for indirect
mapping")
Cc: sta...@vger.kernel.org
Signed-off-by: Gaurav Batra
---
arch/powerpc/platforms/pseries/iommu.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/iommu.c
b/arch/powerpc/platforms/pseries/iommu.c
index 16d93b
port, when DMA window is backed by 2MB TCEs.
Signed-off-by: Gaurav Batra
Reviewed-by: Greg Joyce
Reviewed-by: Brian King
---
arch/powerpc/kernel/iommu.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index
port, when DMA window is backed by 2MB TCEs.
Fixes: 3872731187141d5d0a5c4fb30007b8b9ec36a44d
Signed-off-by: Gaurav Batra
Reviewed-by: Greg Joyce
Reviewed-by: Brian King
---
arch/powerpc/kernel/iommu.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc
ou
prefer. In case
we decide to go with my patch, I just realized that I need to fix
nio_pages in
iommu_free_coherent() as well.
Thanks,
Gaurav
On 4/20/23 10:21 AM, Michael Ellerman wrote:
Gaurav Batra writes:
When DMA window is backed by 2MB TCEs, the DMA address for the mapped
page sho
will resolve Srikar and Mellanox driver issues. The problem is
with 2MB DDW.
Since you have extensive knowledge of IOMMU design and code, in your
opinion, which patch should we adopt?
Thanks a lot
Gaurav
On 4/20/23 2:45 PM, Gaurav Batra wrote:
Hello Michael,
I was looking into the Bug: 199106
(
port, when DMA window is backed by 2MB TCEs.
Fixes: 387273118714 ("powerps/pseries/dma: Add support for 2M IOMMU page size")
Signed-off-by: Gaurav Batra
Reviewed-by: Greg Joyce
Reviewed-by: Brian King
---
arch/powerpc/kernel/iommu.c | 11 +++
1 file changed, 7 insert
ct". Which
essentially means, that a "rogue" device/driver has the potential to
corrupt LPAR wide memory.
I have sent you v3.
Thanks,
Gaurav
On 5/4/23 12:10 AM, Michael Ellerman wrote:
Gaurav Batra writes:
Hello Michael,
I was looking into the Bug: 199106
(https://bugzilla.linu
pointer is
passed in.
Fixes: 381ceda88c4c ("powerpc/pseries/iommu: Make use of DDW for indirect
mapping")
Signed-off-by: Gaurav Batra
Reviewed-by: Brian King
---
arch/powerpc/kernel/dma-iommu.c| 4 +++-
arch/powerpc/platforms/pseries/iommu.c | 13 +
2 files changed,
As of now, in tce_freemulti_pSeriesLP(), there is no limit on how many TCEs
are passed to H_STUFF_TCE hcall. PAPR is enforcing this to be limited to
512 TCEs.
Signed-off-by: Gaurav Batra
Reviewed-by: Brian King
---
arch/powerpc/platforms/pseries/iommu.c | 12 ++--
1 file changed, 10
should I mention the first commit which created this source file?
Thanks a lot for looking into it.
Gaurav
On 5/11/23 9:35 PM, Michael Ellerman wrote:
Gaurav Batra writes:
As of now, in tce_freemulti_pSeriesLP(), there is no limit on how many TCEs
are passed to H_STUFF_TCE hcall. PAPR is enforc
aurav,
Sorry I missed this. Please share the link to the your fix, I do not
see it in my mail. In general, the problem can probably be solved by
using huge pages (anything more than 64K) only for 1:1 mapping.
On 03/05/2023 13:25, Gaurav Batra wrote:
Hello Alexey,
I recently joined IOMMU
On 5/17/23 7:19 AM, Michael Ellerman wrote:
Gaurav Batra writes:
Hello Michael,
System test hit the crash. I believe, it was PHYP that resulted in it
due to number of TCEs passed in to be >512.
OK. It's always good to spell out in the change log whether it's a
theoretical/unl
: sta...@vger.kernel.org
Signed-off-by: Gaurav Batra
Reviewed-by: Brian King
---
arch/powerpc/platforms/pseries/iommu.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/iommu.c
b/arch/powerpc/platforms/pseries/iommu.c
index c74b71d4733d..f159a19
;s current form since the beginning.
Cc: sta...@vger.kernel.org
Signed-off-by: Gaurav Batra
Reviewed-by: Brian King
---
arch/powerpc/platforms/pseries/iommu.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/iommu.c
b/arch/powerpc
This will wipe out those TCEs.
The solution is for iommu_mem_notifier() to only invoke these routines for
"direct" mapped DMA windows.
Signed-off-by: Gaurav Batra
Reviewed-by: Brian King
---
arch/powerpc/platforms/pseries/iommu.c | 17 +
1 file changed, 13 insertio
SeriesLP(), since I would need to hack
kernel to force dynamically added TCEs to the high IO Bus Addresses.
But, the concept is same.
Thanks,
Gaurav
On 6/13/23 12:16 PM, Gaurav Batra wrote:
When memory is dynamically added/removed, iommu_mem_notifier() is invoked. This
routine traverses through
Hello Michael,
Did you get a chance to look into this patch? I don't mean to rush you.
Just wondering if there is anything I can do to help make the patch to
Upstream.
Thanks,
Gaurav
On 6/13/23 12:17 PM, Gaurav Batra wrote:
Hello Michael,
I found this bug while going though the
Thanks a lot
On 6/25/23 11:54 PM, Michael Ellerman wrote:
Gaurav Batra writes:
Hello Michael,
Did you get a chance to look into this patch? I don't mean to rush you.
Just wondering if there is anything I can do to help make the patch to
Upstream.
I skimmed it and decided it was
kdump to succeed.
Fixes: b1fc44eaa9ba ("pseries/iommu/ddw: Fix kdump to work in absence of
ibm,dma-window")
Signed-off-by: Gaurav Batra
Reviewed-by: Brian King
---
arch/powerpc/platforms/pseries/iommu.c | 150 -
1 file changed, 99 insertions(+), 51
On 12/14/23 4:18 AM, Aneesh Kumar K.V wrote:
Gaurav Batra writes:
When kdump kernel tries to copy dump data over SR-IOV, LPAR panics due to
NULL pointer execption.
Here is the complete stack
[ 19.944378] Kernel attempted to read user page (0) - exploit attempt? (uid:
0)^M
[ 19.944388
controller structure is
allocated but there are no calls made to iommu_device_register()
interface.
Fix would be to register iommu device during DLPAR ADD as well.
Fixes: a940904443e4 ("powerpc/iommu: Add iommu_ops to report capabilities and
allow blocking domains")
Signed-off-by: Gau
controller structure is
allocated but there are no calls made to iommu_device_register()
interface.
Fix would be to register iommu device during DLPAR ADD as well.
Fixes: a940904443e4 ("powerpc/iommu: Add iommu_ops to report capabilities and
allow blocking domains")
Signed-off-by: Gau
From: Gaurav Batra
When kdump kernel tries to copy dump data over SR-IOV, LPAR panics due to
NULL pointer execption.
Here is the complete stack
[ 19.944378] Kernel attempted to read user page (0) - exploit attempt? (uid:
0)^M
[ 19.944388] BUG: Kernel NULL pointer dereference on read at
Hello All,
There is still some issue even after applying the patch. This is not a
complete fix. I am working on V3 of the patch. Please do not merge this
patch upstream.
Thanks,
Gaurav
On 1/10/24 4:53 PM, Gaurav Batra wrote:
When a PCI device is Dynamically added, LPAR OOPS with NULL
controller structure is
allocated but there are no calls made to iommu_device_register()
interface.
Fix would be to register iommu device during DLPAR ADD as well.
Fixes: a940904443e4 ("powerpc/iommu: Add iommu_ops to report capabilities and
allow blocking domains")
Signed-off-by: Gaura
kernel_init_freeable+0x344/0x3e4
kernel_init+0x34/0x1d0
ret_from_kernel_user_thread+0x14/0x1c
Fixes: b1fc44eaa9ba ("pseries/iommu/ddw: Fix kdump to work in absence of
ibm,dma-window")
Signed-off-by: Gaurav Batra
---
arch/powerpc/platforms/pseries/iommu.c | 8 +
at 04:12:46PM +1000, Michael Ellerman wrote:
Gaurav Batra writes:
At the time of LPAR reboot, partition firmware provides Open Firmware
property ibm,dma-window for the PE. This property is provided on the PCI
bus the PE is attached to.
AFAICS you're actually describing a bug that happens duri
kernel_init_freeable+0x344/0x3e4
kernel_init+0x34/0x1d0
ret_from_kernel_user_thread+0x14/0x1c
Fixes: b1fc44eaa9ba ("pseries/iommu/ddw: Fix kdump to work in absence of
ibm,dma-window")
Signed-off-by: Gaurav Batra
---
arch/powerpc/platforms/pseries/iommu.c | 8 +
. Maximum size
possible DDW is created as permitted by the Hypervisor.
Signed-off-by: Gaurav Batra
Reviewed-by: Brian King
---
arch/powerpc/include/asm/iommu.h | 2 +
arch/powerpc/platforms/pseries/iommu.c | 71 --
2 files changed, 56 insertions(+), 17 deletions(-)
diff
nding TCEs, sleep for 50ms and check again, until all the TCEs are
unmapped.
Once all the TCEs are unmapped, DDW is removed and DLPAR succeeds. This
ensures there will be no reference to the DDW after it is deleted.
Signed-off-by: Gaurav Batra
---
arch/powerpc/kernel/iommu.c
On 2/5/25 6:43 AM, Donet Tom wrote:
On 1/31/25 00:08, Gaurav Batra wrote:
iommu_mem_notifier() is invoked when RAM is dynamically
added/removed. This
notifier call is responsible to add/remove TCEs from the Dynamic DMA
Window
(DDW) when TCEs are pre-mapped. TCEs are pre-mapped only for RAM
mem_notifier(), PHYP HCALL returns H_PARAMETER. This failed the
command, daxctl, to add pmemory as RAM.
The solution is to not pre-map TCEs for pmemory.
Signed-off-by: Gaurav Batra
---
arch/powerpc/include/asm/mmzone.h | 1 +
arch/powerpc/mm/numa.c | 2 +-
arch/power
unsigned long". This results in
negative value when setting the bitmap.
2. The DMA offset is page shifted but the MMIO range is used as-is (64-bit
address). MMIO address needs to be page shifted as well.
Fixes: 3c33066a2190 ("powerpc/kernel/iommu: Add new iommu_table_in_use()
helper&
dma_supported, with mask less then 64-bit, the
PowerPC IOMMU driver places PHB in the Limited Addressing Mode before
creating DDW.
Signed-off-by: Gaurav Batra
---
arch/powerpc/platforms/pseries/iommu.c | 110 +
1 file changed, 94 insertions(+), 16 deletions(-)
diff --git a/arch
, Gaurav Batra wrote:
iommu_mem_notifier() is invoked when RAM is dynamically added/removed. This
notifier call is responsible to add/remove TCEs from the Dynamic DMA Window
(DDW) when TCEs are pre-mapped. TCEs are pre-mapped only for RAM and not
for persistent memory (pmemory). For DMA buffers in
system_call_vectored_common+0xe8/0x278
Fixes: f431a8cde7f1 ("powerpc/iommu: Reimplement the iommu_table_group_ops for
pSeries")
Signed-off-by: Gaurav Batra
---
arch/powerpc/platforms/pseries/iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platfo
system_call_vectored_common+0xe8/0x278
Fixes: f431a8cde7f1 ("powerpc/iommu: Reimplement the iommu_table_group_ops for
pSeries")
Signed-off-by: Gaurav Batra
---
arch/powerpc/platforms/pseries/iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platfo
hread+0x14/0x18
Signed-off-by: Gaurav Batra
---
arch/powerpc/kernel/iommu.c| 22 --
arch/powerpc/platforms/pseries/iommu.c | 8
2 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iom
On 13/02/2025 18.10, Gaurav Batra wrote:
Some of the network drivers, like Mellanox, use core linux page_pool APIs
to manage DMA buffers. These page_pool APIs cache DMA buffers with
infrequent map/unmap calls for DMA mappings, thus increasing performance.
When a device is initialized, the dr
system_call_vectored_common+0xe8/0x278
Fixes: f431a8cde7f1 ("powerpc/iommu: Reimplement the iommu_table_group_ops for
pSeries")
Signed-off-by: Gaurav Batra
Reviewed-by: Nilay Shroff
Reviewed-by: Ritesh Harjani (IBM)
---
arch/powerpc/platforms/pseries/iommu.c | 2 +-
1 file changed
41 matches
Mail list logo
