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
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
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
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
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
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
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
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
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
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
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
> 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.
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
>
Thanks,
applied to the dma-mapping for-next branch.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
14 matches
Mail list logo