On 23.07.21 03:12, Halil Pasic wrote:
On Thu, 22 Jul 2021 21:22:58 +0200
Christian Borntraeger wrote:
On 20.07.21 15:38, Will Deacon wrote:
Hi again, folks,
This is version two of the patch series I posted yesterday:
https://lore.kernel.org/r/20210719123054.6844-1-w...@kernel.org
> From: Christoph Hellwig
> Sent: Friday, July 23, 2021 1:41 PM
>
> On Fri, Jul 23, 2021 at 05:36:17AM +, Tian, Kevin wrote:
> > > > And a new set of IOMMU-API:
> > > >
> > > > - iommu_{un}bind_pgtable(domain, dev, addr);
> > > > - iommu_{un}bind_pgtable_pasid(domain, dev, addr,
On Fri, Jul 23, 2021 at 05:36:17AM +, Tian, Kevin wrote:
> > > And a new set of IOMMU-API:
> > >
> > > - iommu_{un}bind_pgtable(domain, dev, addr);
> > > - iommu_{un}bind_pgtable_pasid(domain, dev, addr, pasid);
> > > - iommu_cache_invalidate(domain, dev, invalid_info);
> >
> >
> From: Christoph Hellwig
> Sent: Thursday, July 22, 2021 9:35 PM
>
> On Wed, Jun 30, 2021 at 09:08:19AM +, Tian, Kevin wrote:
> > The iommu layer should maintain above attaching status per device and
> per
> > iommu domain. There is no mdev/subdev concept in the iommu layer. It's
> > just
Looks good,
Reviewed-by: Christoph Hellwig
> As a side note, it appears the struct dma_sgt_handle type is exposed
> to users of the DMA-API by linux/dma-map-ops.h, but is has no users
> or functions returning the type explicitly.
>
> This may indicate it's a good idea to move the struct
On Thu, 22 Jul 2021 21:22:58 +0200
Christian Borntraeger wrote:
> On 20.07.21 15:38, Will Deacon wrote:
> > Hi again, folks,
> >
> > This is version two of the patch series I posted yesterday:
> >
> >https://lore.kernel.org/r/20210719123054.6844-1-w...@kernel.org
> >
> > The only changes
Currently, iommu_dma_alloc_noncontiguous() allocates a
struct dma_sgt_handle object to hold some state needed for
iommu_dma_free_noncontiguous().
However, the handle is neither freed nor returned explicitly by
the ->alloc_noncontiguous method, and therefore seems leaked.
This was found by code
On Thu, Jul 22, 2021 at 02:26:08PM -0500, Suthikulpanit, Suravee wrote:
> Lennert,
Hi Suravee,
> > This patch makes iommu/amd call report_iommu_fault() when an I/O page
> > fault occurs, which has two effects:
> >
> > 1) It allows device drivers to register a callback to be notified of
> >
On 20.07.21 15:38, Will Deacon wrote:
Hi again, folks,
This is version two of the patch series I posted yesterday:
https://lore.kernel.org/r/20210719123054.6844-1-w...@kernel.org
The only changes since v1 are:
* Squash patches 2 and 3, amending the commit message accordingly
* Add
On 7/19/2021 3:32 AM, Xiyu Yang wrote:
refcount_t type and corresponding API can protect refcounters from
accidental underflow and overflow and further use-after-free situations.
Signed-off-by: Xiyu Yang
Signed-off-by: Xin Tan
Thanks,
Reviewed-by: Suravee Suthikulpanit
On 7/19/2021 1:00 AM, Xiyu Yang wrote:
refcount_t type and corresponding API can protect refcounters from
accidental underflow and overflow and further use-after-free situations.
Signed-off-by: Xiyu Yang
Signed-off-by: Xin Tan
---
drivers/iommu/amd/iommu_v2.c | 11 ++-
1 file
Lennert,
On 7/19/2021 4:54 AM, Lennert Buytenhek wrote:
This patch makes iommu/amd call report_iommu_fault() when an I/O page
fault occurs, which has two effects:
1) It allows device drivers to register a callback to be notified of
I/O page faults, via the iommu_set_fault_handler() API.
Hi Robin,
I love your patch! Yet something to improve:
[auto build test ERROR on iommu/next]
[also build test ERROR on rockchip/for-next linus/master v5.14-rc2
next-20210722]
[cannot apply to sunxi/sunxi/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when
On 2021-07-22 16:54, Ming Lei wrote:
[...]
If you are still keen to investigate more, then can try either of these:
- add iommu.strict=0 to the cmdline
- use perf record+annotate to find the hotspot
- For this you need to enable psuedo-NMI with 2x steps:
CONFIG_ARM64_PSEUDO_NMI=y in
On 2021-07-22 17:44, kernel test robot wrote:
Hi Robin,
I love your patch! Yet something to improve:
[auto build test ERROR on iommu/next]
[also build test ERROR on rockchip/for-next linus/master v5.14-rc2
next-20210722]
[cannot apply to sunxi/sunxi/for-next]
[If your patch is applied
Hi Shameer,
On Wed, Jul 21, 2021 at 08:54:00AM +, Shameerali Kolothum Thodi wrote:
> > More generally I think this pinned VMID set conflicts with that of
> > stage-2-only domains (which is the default state until a guest attaches a
> > PASID table). Say you have one guest using DOMAIN_NESTED
Hi Robin,
I love your patch! Yet something to improve:
[auto build test ERROR on iommu/next]
[also build test ERROR on rockchip/for-next linus/master v5.14-rc2
next-20210722]
[cannot apply to sunxi/sunxi/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when
On Wed, Jul 21, 2021 at 02:13:23AM +, Tian, Kevin wrote:
> > From: Shenming Lu
> > Sent: Friday, July 16, 2021 8:20 PM
> >
> > On 2021/7/16 9:20, Tian, Kevin wrote:
> > > To summarize, for vIOMMU we can work with the spec owner to
> > > define a proper interface to feedback such restriction
On 7/21/2021 8:44 AM, Lennert Buytenhek wrote:
For the printing of RMP_HW_ERROR / RMP_PAGE_FAULT / IO_PAGE_FAULT
events, the AMD IOMMU code uses such logic:
if (pdev)
dev_data = dev_iommu_priv_get(>dev);
if (dev_data && __ratelimit(_data->rs)) {
On Thu, Jul 22, 2021 at 12:12:05PM +0100, John Garry wrote:
> On 22/07/2021 11:19, Ming Lei wrote:
> > > If you check below, you can see that cpu4 services an NVMe irq. From
> > > checking htop, during the test that cpu is at 100% load, which I put the
> > > performance drop (vs cpu0) down to.
> >
On 2021-07-22 09:16, Peng Ju Zhou via iommu wrote:
the object iova->head allocated statically when enable SRIOV but
freed dynamically when disable SRIOV which causing kmemleak.
changing the allocation from statically to dynamically.
Thanks for the glimpse into the kind of weird and wonderful
On Thu, Jul 22, 2021 at 11:10:24AM +0100, Robin Murphy wrote:
> On 2021-07-22 10:18, Anthony Iliopoulos wrote:
> > Due to link order, dma_debug_init is called before debugfs has a chance
> > to initialize (via debugfs_init which also happens in the core initcall
> > stage), so the directories for
On 22/07/2021 13:53, Marc Zyngier wrote:
Hi John,
[...]
Your kernel log should show:
[ 0.00] GICv3: Pseudo-NMIs enabled using forced ICC_PMR_EL1
synchronisation
Unrelated, but you seem to be running with ICC_CTLR_EL3.PMHE set,
which makes the overhead of pseudo-NMIs much
On Wed, Jun 30, 2021 at 09:08:19AM +, Tian, Kevin wrote:
> The iommu layer should maintain above attaching status per device and per
> iommu domain. There is no mdev/subdev concept in the iommu layer. It's
> just about RID or PASID.
Yes, I think that makes sense.
> And a new set of
On 2021-07-22 12:12, John Garry wrote:
Hi John,
[...]
Your kernel log should show:
[0.00] GICv3: Pseudo-NMIs enabled using forced ICC_PMR_EL1
synchronisation
Unrelated, but you seem to be running with ICC_CTLR_EL3.PMHE set,
which makes the overhead of pseudo-NMIs much higher
On 22/07/2021 11:19, Ming Lei wrote:
If you check below, you can see that cpu4 services an NVMe irq. From
checking htop, during the test that cpu is at 100% load, which I put the
performance drop (vs cpu0) down to.
nvme.poll_queues is 2 in my test, and no irq is involved. But the irq mode
fio
There is already a memory_intersects() helper in sections.h,
use memory_intersects() directly instead of private overlap().
Cc: Christoph Hellwig
Cc: Marek Szyprowski
Cc: Robin Murphy
Cc: iommu@lists.linux-foundation.org
Signed-off-by: Kefeng Wang
---
Resend this patch only.
Due to link order, dma_debug_init is called before debugfs has a chance
to initialize (via debugfs_init which also happens in the core initcall
stage), so the directories for dma-debug are never created.
Move the dma_debug_init initcall from core to postcore stage so that
debugfs will already be
the object iova->head allocated statically when enable SRIOV but
freed dynamically when disable SRIOV which causing kmemleak.
changing the allocation from statically to dynamically.
Signed-off-by: Peng Ju Zhou
---
drivers/iommu/iova.c | 15 ---
include/linux/iova.h | 4 ++--
2
On Thu, Jul 22, 2021 at 11:05:00AM +0100, John Garry wrote:
> On 22/07/2021 08:58, Ming Lei wrote:
> > On Wed, Jul 21, 2021 at 12:07:22PM +0100, John Garry wrote:
> > > On 21/07/2021 10:59, Ming Lei wrote:
> > > > > I have now removed that from the tree, so please re-pull.
> > > > Now the kernel
On 2021-07-22 10:18, Anthony Iliopoulos wrote:
Due to link order, dma_debug_init is called before debugfs has a chance
to initialize (via debugfs_init which also happens in the core initcall
stage), so the directories for dma-debug are never created.
Move the dma_debug_init initcall from core
On 22/07/2021 08:58, Ming Lei wrote:
On Wed, Jul 21, 2021 at 12:07:22PM +0100, John Garry wrote:
On 21/07/2021 10:59, Ming Lei wrote:
I have now removed that from the tree, so please re-pull.
Now the kernel can be built successfully, but not see obvious improvement
on the reported issue:
On Wed, Jul 21, 2021 at 12:07:22PM +0100, John Garry wrote:
> On 21/07/2021 10:59, Ming Lei wrote:
> > > I have now removed that from the tree, so please re-pull.
> > Now the kernel can be built successfully, but not see obvious improvement
> > on the reported issue:
> >
> >
On 2021/7/21 21:59, Robin Murphy wrote:
>> On Wed, 21 Jul 2021 12:42:14 +0100,
>> Robin Murphy wrote:
>>>
>>> [ +Marc for MSI bits ]
>>>
>>> On 2021-07-21 02:33, Bixuan Cui wrote:
Add suspend and resume support for arm-smmu-v3 by low-power mode.
When the smmu is suspended, it is
On Wed, 2021-07-21 at 20:54 +0800, Ikjoon Jang wrote:
> On Thu, Jul 15, 2021 at 8:25 PM Yong Wu wrote:
> >
> > To improve the performance, add initial setting for smi-common.
> > some register use some fix setting(suggested from DE).
> >
> > Signed-off-by: Yong Wu
> > ---
> >
On Wed, 2021-07-21 at 21:40 +0800, Ikjoon Jang wrote:
> On Thu, Jul 15, 2021 at 8:23 PM Yong Wu wrote:
> >
> > To improve the performance, We add some initial setting for smi larbs.
> > there are two part:
> > 1), Each port has the special ostd(outstanding) value in each larb.
> > 2), Two general
Hi Ikjoon,
Thanks very much for your help reviewing..
On Wed, 2021-07-21 at 19:43 +0800, Ikjoon Jang wrote:
> On Thu, Jul 15, 2021 at 8:25 PM Yong Wu wrote:
> >
> > In mt8195, there are some larbs connect with the smi-sub-common, then
> > connect with smi-common.
>
> Not critical but I suggest
On 2021/7/21 23:01, Marc Zyngier wrote:
> On Wed, 21 Jul 2021 14:59:47 +0100,
> Robin Murphy wrote:
>>
>> On 2021-07-21 14:12, Marc Zyngier wrote:
>>> On Wed, 21 Jul 2021 12:42:14 +0100,
>>> Robin Murphy wrote:
[ +Marc for MSI bits ]
On 2021-07-21 02:33, Bixuan Cui wrote:
A gentle ping...
> From: Tian, Kevin
> Sent: Wednesday, June 30, 2021 5:08 PM
>
> > From: Joerg Roedel
> > Sent: Monday, May 17, 2021 11:35 PM
> >
> > On Mon, May 17, 2021 at 10:35:00AM -0300, Jason Gunthorpe wrote:
> > > Well, I'm sorry, but there is a huge other thread talking about the
> > >
39 matches
Mail list logo
