Re: iommu_iova slab eats too much memory

2020-04-24 Thread John Garry
On 24/04/2020 17:30, Robin Murphy wrote: On 2020-04-24 2:20 pm, Bin wrote: Dear Robin: Thank you for your explanation. Now, I understand that this could be NIC driver's fault, but how could I confirm it? Do I have to debug the driver myself? I'd start with CONFIG_DMA_API_DEBUG - of

Re: iommu_iova slab eats too much memory

2020-04-24 Thread Robin Murphy
On 2020-04-24 2:20 pm, Bin wrote: Dear Robin: Thank you for your explanation. Now, I understand that this could be NIC driver's fault, but how could I confirm it? Do I have to debug the driver myself? I'd start with CONFIG_DMA_API_DEBUG - of course it will chew through memory about an

Re: IOVA allocation dependency between firmware buffer and remaining buffers

2020-04-24 Thread Shaik Ameer Basha
On Fri, Apr 24, 2020 at 8:59 PM Robin Murphy wrote: > > On 2020-04-24 4:04 pm, Ajay kumar wrote: > > Can someone check this? > > > > On Mon, Apr 20, 2020 at 9:24 PM Ajay kumar wrote: > >> > >> Hi All, > >> > >> I have an IOMMU master which has limitations as mentioned below: > >> 1) The IOMMU

Re: IOVA allocation dependency between firmware buffer and remaining buffers

2020-04-24 Thread Robin Murphy
On 2020-04-24 4:04 pm, Ajay kumar wrote: Can someone check this? On Mon, Apr 20, 2020 at 9:24 PM Ajay kumar wrote: Hi All, I have an IOMMU master which has limitations as mentioned below: 1) The IOMMU master internally executes a firmware, and the firmware memory is allocated by the same

Re: IOVA allocation dependency between firmware buffer and remaining buffers

2020-04-24 Thread Ajay kumar
Can someone check this? On Mon, Apr 20, 2020 at 9:24 PM Ajay kumar wrote: > > Hi All, > > I have an IOMMU master which has limitations as mentioned below: > 1) The IOMMU master internally executes a firmware, and the firmware memory > is allocated by the same master driver. > The firmware buffer

[PATCH] iommu/omap: Add registration for DT fwnode pointer

2020-04-24 Thread Tero Kristo via iommu
The fwnode pointer must be passed to the iommu core, so that the core can map the IOMMU towards device requests properly. Without this, some IOMMU clients like OMAP remoteproc will fail the iommu configuration multiple times with -EPROBE_DEFER, which will eventually be ignored with a kernel

Re: iommu_iova slab eats too much memory

2020-04-24 Thread Bin
Dear Robin: Thank you for your explanation. Now, I understand that this could be NIC driver's fault, but how could I confirm it? Do I have to debug the driver myself? Robin Murphy 于2020年4月24日周五 下午8:15写道: > On 2020-04-24 1:06 pm, Bin wrote: > > I'm not familiar with the mmu stuff, so what

Re: iommu_iova slab eats too much memory

2020-04-24 Thread Robin Murphy
On 2020-04-24 1:06 pm, Bin wrote: I'm not familiar with the mmu stuff, so what you mean by "some driver leaking DMA mappings", is it possible that some other kernel module like KVM or NIC driver leads to the leaking problem instead of the iommu module itself? Yes - I doubt that intel-iommu

Re: iommu_iova slab eats too much memory

2020-04-24 Thread Bin
I'm not familiar with the mmu stuff, so what you mean by "some driver leaking DMA mappings", is it possible that some other kernel module like KVM or NIC driver leads to the leaking problem instead of the iommu module itself? Bin 于 2020年4月24日周五 20:00写道: > Well, that's the problem! I'm assuming

Re: iommu_iova slab eats too much memory

2020-04-24 Thread Bin
Well, that's the problem! I'm assuming the iommu kernel module is leaking memory. But I don't know why and how. Do you have any idea about it? Or any further information is needed? Robin Murphy 于 2020年4月24日周五 19:20写道: > On 2020-04-24 1:40 am, Bin wrote: > > Hello? anyone there? > > > > Bin

Re: iommu_iova slab eats too much memory

2020-04-24 Thread Robin Murphy
On 2020-04-24 1:40 am, Bin wrote: Hello? anyone there? Bin 于2020年4月23日周四 下午5:14写道: Forget to mention, I've already disabled the slab merge, so this is what it is. Bin 于2020年4月23日周四 下午5:11写道: Hey, guys: I'm running a batch of CoreOS boxes, the lsb_release is: ``` # cat /etc/lsb-release

RE: [PATCH v12 4/8] iommu/vt-d: Add bind guest PASID support

2020-04-24 Thread Tian, Kevin
> From: Jacob Pan > Sent: Wednesday, April 22, 2020 2:53 AM > > When supporting guest SVA with emulated IOMMU, the guest PASID > table is shadowed in VMM. Updates to guest vIOMMU PASID table > will result in PASID cache flush which will be passed down to > the host as bind guest PASID calls.

Re: [PATCH v3] of_device: removed #include that caused a recursion in included headers

2020-04-24 Thread Lee Jones
On Mon, 20 Apr 2020, Hadar Gat wrote: > Both of_platform.h and of_device.h were included each other. > In of_device.h, removed unneeded #include to of_platform.h > and added include to of_platform.h in the files that needs it. > > Signed-off-by: Hadar Gat > Reported-by: kbuild test robot >

Re: [PATCH] dma-contiguous: fix comment for dma_release_from_contiguous

2020-04-24 Thread Christoph Hellwig
Thanks, applied to the dma-mapping for-next branch. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu